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本 书 基于 Android 5.0 版 本 ， 对 Android 开 发 进 阶 要 点 进行 深入 讲解 Broadview’ 
是 高 级 工程 师 成 长 之 路 上 的 必 备 利 路 ， 
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内 容 简介 


本 书 是 一 本 Android 进 阶 关 书籍 ， 采 用 理论 、 源 码 和 实践 相 结合 的 
方式 来 前 述 高 水 准 的 Android 应 用 开发 要 点 。 本 书 从 三 个 方面 来 组 织 内 
容 。 第 一 ， 介 绍 Android 开 及 者 不 容易 掌握 的 一 些 知识 点， 第 二 ， 结 合 
Android 源 代码 和 应 用 层 开发 过 程 ， 融 会 贯通 ， 介 绍 一 些 比较 深入 的 知 
识 点 ;第 三 ， 介 绍 一 些 核心 技术 和 Android 的 性 能 优化 思想 。 


本 书 侧重 于 Android 知 识 的 体系 化 和 系统 工作 机 制 的 分 析 ， 通 过 本 
书 的 学 习 可 以 极 大 地 提高 开发 者 的 Android 技 术 水 平 ， 从 而 更 加 高 效 地 
成 为 高 级 开发 者 。 而 对 于 高 级 开发 者 来 次 ， 仍 然 可 以 从 本 书 的 知识 体系 
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与 玉 刚 共事 两 年 ， 其 对 技术 的 热情 和 执著 让 人 敬佩 ， 其 技术 进步 之 
快 又 让 人 人 惊叹。 如 今 ， 他 把 所 掌握 的 知识 与 经 验 成 书 出 版 ， 是 一 件 大 斑 
之 事 : 于 作者 ， 此 书 是 他 的 心血 所 成 ， 可 豆 可 次 ;于 读者， 可 解 “工作 
视野 ?之 困 与 “ 百 思 不 得 其 解 ” 之 惑 ， 或 许 有 “ 啊 哈 ， 原 来 如 此 ?之 效 ， 又 
或 许 有 “技能 +1” 之 得 意 一 笑 。 





玉 刚 拥有 丰富 的 Android 开 发 经 验 ， 对 Android 开 发 的 很 多 知识 点 都 
有 深入 研究 ， 我 相信 此 书 定 能 为 读者 珊 来 惊喜 。 书 的 内 容 ， 大 抵 有 如 下 
几 方 面 : 基础 知识 点 之 深入 理解 (例如 ，Activity 的 生命 周期 和 启动 模 
式 、Android 的 消息 机 制 分 析 、View 的 事件 体系 、View 的 工作 原理 等 章 
节 ) ; 不 常见 知识 点 的 分 析 例 如 ，IPC 机 制 、 理 解 Window 和 
WindowManager 等 章节) ; 工程 实践 中 的 经 验 ( 例 如 ， 综 合 技术 、 
Android 性 能 优化 等 章节 ) 。 因 此 ， 此 书 读者 需要 有 一 定 的 Android 开 发 
基础 和 工程 经 验 ， 否 则 读 起 来 会 比较 吃力 或 者 感觉 云 里 筋 里 。 对 于 想 成 
长 为 高 级 或 者 资深 Android 研 发 的 工程 师 ， 书 中 的 知识 点 都 是 需要 掌握 
的 。 























最 后 ， 希 望 读 者 能 够 从 此 书 获 益 ， 接 触 到 一 些 工作 中 未 曾 了 解 或 者 
思考 的 知识 点 。 更 进一步 ， 布 望 读 者 能 够 活 学 活用 ， 并 学 习 此 书 背后 的 
钻研 精神 。 
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百度 手机 卫士 ”资深 工程 师 


从 目前 的 形势 来 看 ，Android 开 发 相当 火热 ， 但 是 高 级 Android 开 发 
人 才 却 比 较 少 ， 当 然 在 国内 ， 不 仅仅 是 Android， 其 他 技术 岗位 同样 面 
临 这 个 问题 。 试 想 下 ， 如 果 有 一 本 书 能 够 切实 有 效 地 提高 开发 者 的 技术 
水 平 ， 那 该 多 好 啊 ! 纵 观 市 场 上 的 Android 书 籍 ， 很 多 都 是 入 门类 书 
籍 ， 还 有 一 些 Android 源 码 分 析 、 系 统 移植 、 驱 动 开发 、 逆 辐 工 程 等 系 
统 底层 类 书籍 。 入 门类 书籍 是 目前 图 书市 场 中 的 中 坚 力 量 ， 它 们 在 帮助 
开发 者 入 门 的 过 程 中 起 到 了 非常 重要 的 作用 ， 但 开发 者 在 想 进一步 提高 
技术 水 平 ， 还 需要 阅读 更 深入 的 书籍 。 底 层 书 籍 包括 源码 分 析 、 驱 动 开 
发 、 逆 同 工 程 等 书籍 ， 它 们 从 底层 或 者 某 一 个 特殊 的 角度 来 深入 地 分 析 
Android， 这 是 很 值得 称赞 和 学 习 的 ， 通 过 这 些 书 可 以 极 大 地 提高 开发 
者 底层 或 者 相关 领域 的 技术 水 平 。 但 美中不足 的 是 ， 系 统 底层 书籍 比较 
偶 理 论 ， 部 分 开发 者 阅读 起 来 可 能 会 有 点 临 泌 难 懂 。 更 重要 的 一 点 ， 由 
于 它们 往往 侧重 原理 和 底层 机 制 ， 导 致 它们 不 能 直接 为 应 用 层 开发 服 
务 ， 毕 竟 绝 大 多 数 Android 开 发 岗位 都 是 应 用 层 开 发 。 由 于 阅读 底层 类 
书籍 一 般 只 能 够 加 深 对 底层 的 认识 ， 而 在 应 用 层 开 发 中 ， 还 是 不 能 形成 
直接 有 效 的 战斗 力 ， 这 中 间 是 需要 转化 过 程 的 。 但 是 ， 由 于 部 分 开发 者 
缺乏 相应 的 技术 功底 ， 导 致 无 法 完成 这 个 转化 过 程 。 




















可 以 发 现 ， 目 前 市 场 上 既 能 够 极 大 地 提高 开发 者 的 应 用 层 技术 经 
验 ， 叉 能 够 将 上 层 和 系统 底层 的 运行 机 制 结合 起 来 的 书籍 还 是 比较 少 
的 。 对 企业 来 说 ， 在 业务 上 有 很 强 的 技术 能 力 ， 同 时 对 Android 压 层 也 
有 一 定理 解 的 开发 人 员 ， 是 企业 比较 青睐 的 技术 高 手 。 为 了 完成 这 一 原 








望 ， 笔 者 写 了 这 本 书 。 通 过 对 本 书 的 深入 学 习 ， 开 发 者 既 能 够 极 大 地 提 
高 应 用 层 的 开发 能 力 ， 又 能 够 对 Android 系 统 的 运行 机 制 有 一 定 的 理 
解 ， 但 如 果 要 深入 理解 Android 的 后 层 机 制 ， 仍 然 需 要 查看 相关 源码 分 
析 的 书籍 。 


本 书 适 合 各 类 开发 者 阅读 ， 对 于 初 、 中 级 开发 者 来 说 ， 可 以 通过 本 
书 更 加 高 效 地 达到 高 级 开发 者 的 撤 术 水 平 。 而 对 于 高 级 开发 者 ， 仍 然 可 
以 从 本 书 的 知识 体系 中 获 蔓 。 本 书 的 书 名 之 所 以 采用 艺术 这 个 词 ， 这 是 
因为 在 笔者 眼中 ， 代 码 写 到 极致 就 是 一 种 艺术 。 








本 文 内 容 
本 书 共 15 章 ， 所 讲述 的 内 容 均 基于 Android 5.0 系 统 。 


第 1 章 介 绍 Activity 的 生命 周期 和 局 动 模式 以 及 IntentFilter 的 匹配 规 
则 。 





第 2 章 介 绍 Android 中 常见 的 IPC 机 制 ， 多 进程 的 运行 模式 和 一 些 常 
见 的 进程 间 通 信 方 式 ， 包 括 Messenger、AIDL、Binder 以 及 
ContentProvider 等 ， 同 时 还 介绍 Binder 连 接 池 的 概念 。 


第 3 章 介 绍 View 的 事件 体系 ， 并 对 View 的 基础 知识 、 滑 动 以 及 弹性 
滑动 做 详细 的 介绍 ， 同 时 还 深入 分 析 滑 动 冲 突 的 原因 以 及 解决 方法 。 


第 4 章 介 绍 View 的 工作 原理 ， 首 先 介 绍 ViewRoot、DecorView、 
MeasureSpec 等 View 相 关 的 底层 概念 ， 然 后 详细 分 析 View 的 测量 、 布 局 
和 绘制 三 大 流程 ， 最 后 介绍 自 定 义 View 的 分 类 以 及 实现 思想 。 





第 5 章 讲 述 一 个 不 常见 的 概念 RemoteViews， 分 别 描述 RemoteViews 
在 通知 栏 和 泉 面 小 部 件 中 的 使 用 场景 ， 同 时 还 详细 介绍 PendingIntent， 





最 后 深入 分 析 RemoteViews 的 内 部 机 制 并 探索 性 地 指出 RemoteViews 在 
Android 中 存在 的 意义 。 


第 6 章 对 Android 的 Drawable 做 一 个 全 面 性 的 介绍 ， 除 此 之 外 还 讲解 
自 定义 Drawable 的 方法 。 


第 7 章 对 Android 中 的 动画 做 一 个 全 面 深入 的 分 机， 包含 View 动 画 和 
属性 动画 。 


第 8 章 讲述 Window 和 WindowManager， 首 先 分 析 Window 的 内 部 工 
作 原 理 ， 包 括 Window 的 添加 、 更 新 和 删除 ， 其 次 分 析 Activity、Dialog 
等 类 型 的 Window 对 象 的 创建 过 程 。 


第 9 章 深 入 分 析 Android 中 四 大 组 件 的 工作 过 程 ， 主 要 包括 四 大 组 件 
的 运行 状态 以 及 它们 主要 的 工作 过 程 ， 比 如 局 动 、 绑 定 、 广 播 的 发 送 和 
接收 等 。 


第 10 章 深入 分 析 Android 的 消息 机 制 ， 其 中 涉及 的 概念 有 Handler、 
Looper、MessageQueue 以 及 ThreadLocal， 此 外 还 分 析 主 线程 的 消息 循环 
模型 。 


第 11 章 讲述 Android 的 线程 和 线程 池 ， 首 先 介 绍 AsyncTask、 
HandlerThread、IntentService 以 及 ThreadPoolExecutor 的 使 用 方法 ， 然 后 
分 析 它 们 的 工作 原理 。 


第 12 章 讲述 的 主题 是 Bitmap 的 加 载 和 缓存 机 制 ， 首 先 讲 述 高 效 加 载 
图 片 的 方式 ， 接 着 介绍 LruCache 和 DiskLruCache 的 使 用 方法 ， 最 后 通过 
一 个 ImageLoader 的 实例 来 将 它们 综合 起 来 。 








第 13 章 是 综合 拉 术 ， 讲 述 一 些 很 重要 但 是 不 太 常 见 的 拉 术 方 采 ， 它 


们 是 CrashHandler、multidex、 插 件 化 以 及 反 编 译 。 
第 14 章 的 主题 是 JNI 和 NDK 编 程 ， 介 绍 使 用 JNI 和 Android NDK 编 程 
WATE 


第 15 章 介绍 Android 的 性 能 优化 方法 ， 比 如 常见 的 布局 优化 、 绘 制 
优化 、 内 存 泄露 优化 等 ， 除 此 之 外 还 介绍 分 析 ANR 和 内 存 泄 露 的 方法 ， 
最 后 探讨 如 何 提高 程序 的 可 维护 性 这 一 话题 。 





通过 这 15 章 的 学 习 ， 可 以 让 初 、 中 级 开发 者 的 技术 水 平和 把 控 能 
提升 一 个 档次 ， 最 终 成 为 高 级 开发 者 。 





本 书 特色 


本 书 定 位 为 进 阶 类 图 书 ， 不 会 对 一 些 基 础 知识 从 头 说 起 ， 或 者 说 每 
一 章节 都 不 通关 各 种 入 门 知识 ， 但 是 在 同 高 级 知识 点 过 湾 的 时 候 ， 会 入 
微 提 及 一 下 基础 知识 从 而 做 到 平滑 过 渡 。 开 发 者 在 掌握 入 门 知 识 以 后 ， 
通过 本 书 可 以 极 大 地 提高 应 用 层 开发 的 技术 水 平 ， 同 时 还 可 以 理解 一 定 
的 Android 底 层 运行 机 制 ， 并 且 能 够 将 它们 进行 升华 从 而 更 好 地 为 应 用 
层 开 及 服务 。 除 了 这 些 ， 开 发 者 还 可 以 掌握 一 些 核 心 技术 和 性 能 优化 思 
想 ， 本 书 涉及 的 知识 ， 都 是 一 个 合格 的 高 级 工程 师 所 必须 掌握 的 。 人 简单 
地 说 ， 本 书 的 目的 就 是 让 初 、 中 级 开发 者 更 有 针对 性 地 营 握 高 级 工程 师 
所 应 该 掌握 的 技术 ， 能 够 让 初 、 中 级 开发 者 按照 正确 的 道路 快速 地 成 长 
为 高 级 工程 师 。 
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1 Activity 的 生命 周期 和 局 
动 模式 





作为 本 书 的 第 1 章 ， 本 章 主 要 介绍 Activity 相 关 的 一 些 内 容 。Activity 
作为 四 大 组 件 之 省， 是 使 用 最 为 频繁 的 一 种 组 件 ， 中 文 直接 翻译 为 “ 活 
By”, 但 是 笔者 认为 这 种 翻译 有 些 生硬 ， 如 果 翻 译 成 界面 就 会 更 好 理 
解 。 正 常情 况 下 ， 除 了 Window、Dialog 和 Toast， 我 们 能 见 到 的 界面 的 
确 只 有 Activity。Activity 是 如 此 重要 ， 以 至 于 本 书 开篇 就 不 得 不 讲 到 
它 。 当 然 ， 由 于 本 书 的 定位 为 进 阶 书 ， 所 以 不 会 介绍 如 何 局 动 Activity 
这 类 入 门 知识 ， 本 章 的 侧重 点 是 Activity 在 使 用 过 程 中 的 一 些 不 容易 搞 
清 
Bs 





清楚 的 概念 ， 主 要 包括 生命 周期 和 局 动 模式 以 及 IntentFilter 的 匹配 规则 

析 。 其 中 Activity 在 异常 情况 下 的 生命 周期 是 十 分 微妙 的 ， 至 于 
Activity 的 启动 模式 和 形形色色 的 Flags 更 是 让 初学 者 摸 不 到 头脑 ， 就 连 
隐 式 启动 Activity 中 也 有 着 复杂 的 Intent 匹 配 过 程 ， 不 过 不 用 担心 ， 本 章 
接 下 来 将 一 一 解 开 这 些 疑 难 问题 的 神秘 面纱 。 








1.1 Activity 的 生命 周期 全 面 分 析 


本 节 将 Activity 的 生命 周期 分 为 两 部 分 内 容 ， 一 部 分 是 典型 情况 下 
的 生命 周期 ， 男 一 部 分 是 异常 情况 下 的 生命 周期 。 所 谓 典 型 情况 下 的 生 
命 周 期 ， ‘ili 在 有 用 户 参 与 的 情况 下 ，Activity 所 经 过 的 生命 周期 的 改 
Ae, 而 异常 情况 下 的 生命 bi clas Gos aie ennai 于 当前 设 
备 的 Configuration 发 生 改 变 从 而 导致 Activity 被 销毁 重建 ， 异 常情 况 下 的 
生命 周期 的 关注 点 和 典型 情况 下 略 有 不 同 。 


1.1.1 典型 情况 下 的 生命 周期 分 析 


在 正常 情况 下 ，Activity 会 经 历 如 下 生命 周期 。 











(1) onCreate: 表示 Activity 正 在 被 创建 ， 这 是 生命 周期 的 第 一 个 
方法 。 在 这 个 方法 中 ， 我 们 可 以 做 一 些 初 始 化 工作 ， 比 如 调用 
setContentView 去 加 载 界 面 布局 资源 、 初 始 化 Activity 所 需 数据 等 。 








(2) onRestart: 表示 Activity 正 在 重新 启动 。 一 般 情 况 下 ， 当 当前 
Activity 从 不 可 见 重新 变 为 可 见 状态 时 ，onRestart 就 会 被 调用 。 这 种 情形 
一 般 是 用 户 行 为 所 导致 的 ， 比 如 用 户 按 Home 键 切换 到 桌面 或 者 用 户 打 
开 了 一 个 新 的 Activity， 这 时 当前 的 Activity 就 会 暂停 ， 也 就 是 onPause 和 
onStop 被 执行 了 ， 接 着 用 户 又 回 到 了 这 个 Activity， 就 会 出 现 这 种 情况 。 


(3) onStart: ly 动 ， 即 将 开始 ， A Aaii 已 
经 可 见 了 ， 但 是 还 没有 出 现在 前 合 ， 还 无 法 和 用 户 交 互 。 这 个 时 候 其 实 


可 以 理解 为 Activity 已 经 显示 出 来 了 ， 但 是 我 们 还 看 不 到 。 


(4) onResume: 表示 Activity 已 经 可 见 了 ， 并 且 出 现在 前 人 台 并 开始 
活动 。 要 注意 这 个 和 onStart 的 对 比 ，onStart 和 onResume 都 表示 Activity 
已 经 可 见 ， 但 是 onStart 的 时 候 Activity 还 在 后 台 ，onResume 的 时 候 
Activity 才 显示 到 前 台 。 


(5) onPause: 表示 Activity 正 在 停止 ， 正 常情 况 下 ， 紧 接着 onStop 
就 会 被 调用 。 在 特殊 情况 下 ， 如 果 这 个 时 候 快速 地 再 回 到 当前 
Activity， 那 么 onResume 会 被 调用 。 笔 者 的 理解 是 ， 这 种 情况 属于 极端 
情况 ， 用 户 操 作 很 难 重 现 这 一 场景 。 此 时 可 以 做 一 些 存 储 数据 、 仿 止 动 
男 等 工作 ， 但 是 注意 不 能 太 耗 时 ， 因 为 这 会 影响 到 新 Activity 的 显示 ， 
onPause 必 须 先 执行 完 ， 新 Activity 的 onResume 才 会 执行 。 








(6) onStop: 表示 Activity 即 将 停止 ， 可 以 做 一 些 稍微 重量 级 的 回 
收工 作 ， 同 样 不 能 太 耗 时 。 


(7) onDestroy: 表示 Activity 即 将 被 销毁 ， 这 是 Activity 生 命 周 期 
中 的 最 后 一 个 回调 ， 在 这 里 ， 我 们 可 以 做 一 些 回 收工 作 和 最 终 的 资源 释 
放 。 


正常 情况 下 ，Activity 的 常用 生命 周期 就 只 有 上 面 7 个 ， 图 1-1 更 详细 
地 摘 述 了 Activity 各 种 生命 周期 的 切换 过 程 。 


( Activity 启 动 | 


| 


onCreate 
onStart 一 一 一 onRestart 


























用 户 返 回 原 Activity J 
onResume 
| 应 用 被 杀 死 ) | Activity 运 行 | 
新 Activity 启 动 
”用 户 返 回 原 Activity 
高 优先 级 的 应 用 需要 内 存 onPause 
Activity 已 经 不 可 见 





’ | 用 户 返 回 原 Activity 
onStop 
| 


Activity 正 在 停止 或 者 即将 被 销毁 





| onDestroy | 
| Activity 销 毁 
图 1-1 Activity 生命 周期 的 切换 过 程 


针对 图 1-1， 这 里 再 附加 一 下 其 体 说 明 ， 分 如 下 儿 种 情况 。 


(1) 针对 一 个 特定 的 Activity， 第 一 次 启动 ， 回 调 如 下 : onCreate - 


> onStart -> onResume. 


(2) 当 用 户 打开 新 的 Activity 或 者 切换 到 架 面 的 时 候 ， 回 调 如 下 : 


onPause -> onStop。 这 里 有 一 种 特殊 情况 ， 如 果 新 Activity 采 用 了 透明 主 
题 ， 那 么 当前 Activity 不 会 回调 onStop。 


(3) 当 用 户 再 次 回 到 原 Activity 时 ， 回 调 如 下 : onRestart -> onStart 


-> onResume. 


(4) 当 用 户 按 back 键 回 退 时 ， 回 调 如 下 : onPause -> onStop -> 


onDestroy. 


(5) 当 Activity 被 系统 回收 后 再 次 打开 ， 生 命 周期 方法 回调 过 程 和 
(1) 一 样 ， 注 意 只 是 生命 周期 方法 一 样 ， 不 代表 所 有 过 程 都 一 样 ， 这 
个 问题 在 下 一 市 会 详细 说 明 。 


(6) 从 整个 生命 周期 来 说 ，onCreate 和 onDestroy 是 配对 的 ， 分 别 
标识 着 Activity 的 创建 和 销毁 ， 并 且 只 可 能 有 一 次 调用 。 从 Activity 是 否 
可 见 来 说 ，onStart 和 onStop 是 配对 的 ， 随 着 用 户 的 操作 或 者 设备 屏幕 的 
CRS RK, PAST IE BEB eK; 从 Activity 是 人 否 在 前 人 台 来 
说 ，onResume 和 onPause 是 配对 的 ， 随 着 用 户 操作 或 者 设备 屏幕 的 点 亮 
和 煜 灭 ， 这 两 个 方法 可 能 被 调用 多 次 。 











这 里 提出 2 个 问题 ， 不 知道 大 家 是 售 清 楚 。 


问题 1: onStart 和 onResume、onPause 和 onStop 从 描述 上 来 看 差 不 
多 ， 对 我 们 来 说 有 什么 实质 的 不 同 呢 ? 


问题 2: 假设 当前 Activity 为 A， 如 果 这 时 用 户 打 开 一 个 新 Activity 
B， 那 么 B 的 onResume 和 A 的 onPause 哪 个 先 执行 呢 ? 


先 说 第 一 个 问题 ， 从 实际 使 用 过 程 来 说 ，onStart 和 onResume、 
onPause 和 onStop 看 起 来 的 确 差 不 多 ， 甚 至 我 们 可 以 只 保留 其 中 一 对 ， 比 





如 只 保留 onStart 和 onStop。 既 然 如 此 ， 那 为 什么 Android 系 统 还 要 提供 看 
起 来 重复 的 接口 呢 ? 根据 上 面 的 分 析 ， 我 们 知道 ， 这 两 个 配对 的 回调 分 
别 表示 不 同 的 意义 ，onStart 和 onStop 是 从 Activity 是 否 可 见 这 个 角度 来 回 
调 的 ， 而 onResume 和 onPause 是 从 Activity 是 否 位 于 前 台 这 个 角度 来 回调 
的 ， 除 了 这 种 区 别 ， 在 实际 使 用 中 没有 其 他 明显 区 别 。 











第 二 个 问题 可 以 从 Android 源 码 里 得 到 解释 。 关 于 Activity 的 工作 原 
理 在 本 书后 续 和 章节 会 进行 介绍 ， 这 里 我 们 先 大 概 了 解 即 可 。 从 Activity 
的 启动 过 程 来 看 ， 我 人 bee —F 系统 源码 。Activity 的 启动 过 程 的 源码 
相当 复杂 ， 涉 及 Instrumentation、ActivityThread 和 
ActivityManagerService 〈 下 面 简称 AMS) 。 这 里 不 详细 分 析 这 一 过 程 ， 
简单 理解 ， 启 动 Activity 的 请 求 会 由 Instrumentation 来 处 理 ， 然 后 它 通过 
Binder JAMS 请求，AMS 内 部 维护 着 一 个 ActivityStack 并 负 贡 栈 内 的 
Activity 的 状态 同步 ，AMS 通 过 ActivityThread 去 同步 Activity 的 状态 从 而 
完成 生命 周期 方法 的 调用 。 中 的 resumeTopActivity- 
InnerLocked 方 法 中 ， 有 这 么 一 段 代码 : 





// We need to start pausing the current activity so the top o 
// can be resumed... 
boolean dontWaitForPause = (next.info.flags&ActivityInfo.FLAG 
boolean pausing = mStackSupervisor .pauseBackStacks(userLeavin 
if (mResumedActivity != null) { 

pausing |= startPausingLocked(userLeaving, false, true, dont 


if (DEBUG_STATES) Slog.d(TAG, "resumeTopActivityLocked: Pa 


从 上 述 代 码 可 以 看 出 ， 在 新 Activity 启 动 之 前 ， 栈 顶 的 Activity 需 要 
先 onPause 后 ， 新 Activity 才 能 启动 。 最 终 ， 在 ActivityStackSupervisor 中 





的 realStartActivityLocked 方 法 会 调用 如 下 代码 。 


app.thread.scheduleLaunchActivity(new Intent(r.intent),r.appT 
System.identityHashCode(r),r.info,new Configurati 
r.compat,r.task.voiceInteractor,app.repProcState, 
results, newIntents, !andResume, mService.isNextTran 


profileriInfo); 


我 们 知道 ， 这 个 app.thread 的 类 型 是 IApplicationThread， 而 
IApplicationThread 的 具体 实现 是 ActivityThread 中 的 ApplicationThread。 
所 以 ， 这 段 代 码 实际 上 调 到 了 ActivityThread 的 中 ， 即 ApplicationThread 
的 scheduleLaunchActivity 方 法 ， 而 scheduleLaunchActivity 方 法 最 终 会 完 
成 新 Activity 的 onCreate、onStart、onResume 的 调用 过 程 。 因 此 ， 可 以 得 
出 结论 ， 是 旧 Activity 先 onPause， 然 后 新 Activity 再 启动 。 





至 于 ApplicationThread 的 ScheduleLaunchActivity 方 法 为 什么 会 完成 
新 Activity 的 onCreate、onStart、onResume 的 调用 过 程 ， 请 看 下 面 的 代 
人 码 。scheduleLaunchActivity 最 终 会 调用 如 下 方法 ， 而 如 下 方法 的 确 会 完 
成 onCreate、onStart、onResume 的 调用 过 程 。 


源码 : ActivityThread#handleLaunchActivity 


private void handleLaunchActivity(ActivityClientRecord r, Inte 
// If we are getting ready to gc after going to the backg 
// we are back active so skip it. 
unscheduleGcIdler(); 
mSomeActivitiesChanged = true; 


if (r.profilerInfo != null) { 


mProfiler.setProfiler(r.profileriInfo); 
mProfiler.startProfiling(); 
J 
// Make sure we are running with the most recent config. 
handleConfigurationChanged(null, null); 
if (localLOGV) Slog.v( 
TAG, "Handling launch of " + r); 
// 这 里 新 Activity 被 创建 出 来 ， 其 onCreate 和 onStart 会 被 调用 





Activity a = performLaunchActivity(r,customIntent); 
if (a != null) { 
r.createdConfig = new Configuration(mConfiguratio 
Bundle oldState = r.state; 
// 这 里 新 Activity 的 onResume 会 被 调用 
handleResumeActivity(r.token, false, r.isForward, 


lr.activity.mFinished && !r.start 


// B 


从 上 面 的 分 析 可 以 看 出 ， 当 新 启动 一 个 Activity 的 时 候 ， 旧 Activity 





的 onPause 会 先 执 行 ， 然 后 才 会 局 动 新 的 Activity。 到 底 是 不 是 这 样 呢 ? 
我 们 写 个 例子 验证 一 下 ， 如 下 是 2 个 Activity 的 代码 ， 在 MainActivity 中 单 
0 同时 为 了 分 析 我 们 的 问题 ， 在 生命 
周期 方法 中 打印 出 了 日 志 ， 通 过 日 志 我 们 残 能 看 出 它们 的 调用 顺序 。 


代码 : MainActivity. java 


public class MainActivity extends Activity { 


private static final String TAG = "MainActivity"; 


代码 : SecondActivity. java 





t 

@Override 

protected void onResume() { 
super .onResume(); 


Log.d(TAG, "onResume" ) ; 


} 


我 们 来 看 一 下 log， 是 不 是 和 我 们 上 面 分 析 的 一 样 ， 如 图 1-2 所 示 。 








Level Time PID TID Application Tag Text 
D 1 01:37:33 1 a 724 com.ryg.chapter_1 MainActivity onPause 
02-01 01:37:33.111 724 724 com.ryg.chapter_1 SecondActivity onCreate 
1 01:37:533.11 4 = com.ryg.chapter_1 SecondActivity onStart 
01 333.12 724 a com.ryg.chapter_1 SecondActivity onResume 
02-01 01:37:33.431 724 4 com.ryg.chapter_1 MainActivity onStop 





图 1-2 Activity 生 命 周期 方法 的 回调 顺序 


通过 图 1-2 可 以 发 现 ， 旧 Activity 的 onPause 先 调用 ， 然 后 新 Activity 
才 局 动 ， 这 也 证 实 了 我 们 上 面 的 分 析 过 程 。 也 许 有 人 会 问 ， 你 只 是 分 析 
了 Android5.0 的 源码 ， 你 怎么 知道 所 有 版 本 的 源码 都 是 相同 逻辑 呢 ?” 关 
于 这 个 问题 ， 我 们 的 确 不 大 可 能 把 所 有 版 本 的 源码 都 分 析 一 和 过， 但 是 作 
为 Android 运 行 过 程 的 基本 机 制 ， 随 着 版 本 的 更 新 并 不 会 有 大 的 调整 ， 
因为 Android 系 统 也 需要 兼容 性 ， 不 能 说 在 不 同 版 本 上 同一 个 运行 机 制 
有 着 截然 不 同 的 表现 。 关 于 这 一 点 我 们 需要 把 握 一 个 度 ， 就 是 对 于 
Android 运 行 的 基本 机 制 在 不 同 Android 版 本 上 具有 延续 性 。 从 男 一 个 角 
度 来 说 ，Android 官 方 文档 对 onPause 的 解释 有 这 么 一 句 : 不 能 在 onPause 
中 做 重量 级 的 操作 ， 因 为 必须 onPause 执 行 完 成 以 后 新 Activity 才 能 
Resume， 从 这 一 点 也 能 间接 证 明 我 们 的 结论 。 通 过 分 析 这 个 问题 ， 我 
们 知道 onPause 和 onStop 都 不 能 执行 耗 时 的 操作 ， 尤 其 是 onPause， 这 也 


意味 着 ， 我 们 应 当 尺 量 在 onStop 中 做 操作 ， 从 而 使 得 新 Activity 尺 快 最 示 
出 来 并 切换 到 前 台 。 


1.1.2” 异 利 情 况 下 的 生命 周期 分 析 


上 一 节 我 们 分 析 了 典型 情况 下 Activity 的 生命 周期 ， 本 节 我 们 接着 
分 析 Activity 在 异常 情况 下 的 生命 周期 。 我 们 知道 ，Activity 除 了 受用 户 
操作 所 导致 的 正常 的 生命 周期 方法 调度 ， 还 有 一 些 异常 情况 ， 比 如 当 资 
源 相关 的 系统 配置 发 生 改 变 以 及 系统 内 存 不 足 时 ，Activity 就 可 能 被 杀 
死 。 下 面 我 们 具体 分 析 这 两 种 情况 。 


1. 情况 1:， 资源 相关 的 系统 配置 发 生 改 变 导 致 Activity 被 杀 死 并 重 
新 创建 


理解 这 个 问题 ， 我 们 首先 要 对 系统 的 资源 加 载 机 制 有 一 定 了 解 ， 这 
里 不 详细 分 析 系 统 的 资源 加 载 机 制 ， 只 是 简单 说 明 一 下 。 拿 最 简单 的 图 
片 来 说 ， 当 我 们 把 一 张 图 片 放 在 drawable 目 录 后 ， 就 可 以 通过 Resources 
去 获取 这 张 图 片 。 同 时 为 了 兼容 不 同 的 设备 ， 我 们 可 能 还 需要 在 其 他 一 
些 目 录放 置 不 同 的 图 片 ， 比 如 drawable-mdpi、drawable-hdpi、drawable- 
land 等 。 这 样 ， 当 应 用 程序 启动 时 ， 系 统 就 会 根据 当前 设备 的 情况 去 加 
载 合适 的 Resources 资 源 ， 比 如 说 横 屏 手机 和 竖 屏 手机 会 拿 到 两 张 不 同 的 
图 片 “ 设 定 了 landscape 或 者 portrait 状 态 下 的 图 片 ) 。 比 如 说 当前 Activity 
处 于 竖 屏 状态 ， 如 采 突 然 旋 转 屏 幕 ， 由 于 系统 配置 发 生 了 改变 ， 在 默认 
情况 下 ，Activity 束 会 被 销毁 并 且 重 新 创建 ， 当 然 我 们 也 可 以 阻止 系统 
重新 创建 我 们 的 Activity。 





在 默认 情况 下 ， 如 果 我 们 的 Activity 不 做 特殊 处 理 ， 那 么 当 系统 配 


置 友 生 改变 后 ，Activity 就 会 被 销毁 并 重新 创建 ， 其 生命 周期 如 图 1-3 所 
不 。 




















Activity Activity 
意外 情况 | 
v | 
onSavelnstanceState ”一 重新 创建 -| onCreate 
onDestory _onRestorelnstanceState 








图 1-3 异常 情况 下 Activity 的 重建 过 程 


当 系 统 配置 发 生 改 变 后 ，Activity 会 被 销毁 ， 其 onPause、onStop、 
onDestroy 均 会 被 调用 ， 同 时 由 于 Activity 是 在 异常 情况 下 终止 的 ， 系 统 
会 调用 onSaveInstanceState 来 保存 当前 Activity 的 状态 。 这 个 方法 的 调用 
时 机 是 在 onStop 之 前 ， 它 和 onPause 没 有 既定 的 时 序 关 系 ， 它 既 可 能 在 
onPause 之 前 调用 ， 也 可 能 在 onPause 之 后 调用 。 需 要 强调 的 一 点 是 ， 这 
个 方法 只 会 出 现在 Activity 被 异常 终止 的 情况 下 ， 正 常情 况 下 系统 不 会 
回调 这 个 方法 。 当 Activity 被 重新 创建 后 ， 系 统 会 调用 
onRestoreInstanceState， 并 且 把 Activity 销 毁 时 onSaveInstanceState 方 法 所 
保存 的 Bundle 对 象 作 为 参数 同时 传递 给 onRestoreInstanceState 和 onCreate 
方法 。 因 此 ， 我 们 可 以 通过 onRestoreInstanceState 和 onCreate 方 法 来 判断 
Activity 是 否 被 重建 了 ， 如 果 被 重建 了 ， 那 么 我 们 束 可 以 取出 之 前 保存 
的 数据 并 恢复 ， 从 时 序 上 来 说 ，onRestoreInstanceState 的 调用 时 机 在 
onStart 之 后 。 


同时 ， 我 们 要 知道 ， 在 onSaveInstanceState 和 onRestoreInstanceState 
方法 中 ， 系 统 自 动 为 我 们 做 了 一 定 的 恢复 工作 。 当 Activity 在 异常 情况 
下 需要 重新 创建 时 ， 系 统 会 默认 为 我 们 保存 当前 Activity 的 视图 结构 ， 
并 且 在 Activity 重 启 后 为 我 们 恢复 这 些 数据 ， 比 如 文本 框 中 用 户 输入 的 
数据 、ListView 滚 动 的 位 置 等 ， 这 些 View 相 关 的 状态 系统 都 能 够 默认 为 
我 们 恢复 。 有 具体 针对 某 一 个 特定 的 View 系 统 能 为 我 们 恢复 哪些 数据 ， 我 
们 可 以 查看 View 的 源码 。 和 Activity 一 样 ， 每 个 View 都 有 
onSaveInstanceState 和 onRestoreInstanceState 这 两 个 方法 ， 看 一 下 它们 的 
具体 实现 ， 就 能 知道 系统 能 够 自动 为 每 个 View 恢 复 哪 些 数 据 。 





关于 保存 和 恢复 View 层 次 结构 ， 系 统 的 工作 流程 是 这 样 的 :首先 
Activity 被 意外 终止 时 ，Activity 会 调用 onSaveInstanceState 去 保存 数据 ， 
然后 Activity 会 委托 Window 去 保存 数据 ， 接 着 Window 再 委托 它 上 面 的 顶 
级 容器 去 保存 数据 。 顶 层 容器 是 一 个 ViewGroup， 一 般 来 说 它 很 可 能 是 
DecorView。 最 后 项 层 容器 再 去 一 一 通知 它 的 子 元 素来 保存 数据 ， 这 样 





整个 数据 保存 过 程 束 完成 了 。 可 以 发 现 ， 这 是 一 种 典型 的 委托 思想 ， 上 
层 委 托 下 层 、 父 容 莫 委托 子 元 素 去 处 理 一 件 事情 ， 这 种 思想 在 Android 





中 有 很 多 应 用 ， 比 如 View 的 绘制 过 程 、 事 件 分 发 等 都 是 采用 类 似 的 思 
想 。 全 于 数据 恢复 过 程 也 是 类 似 的 ， 这 里 吏 不 再 重复 介绍 了 。 接 下 来 举 
个 例子 ， 拿 TextView 来 说 ， 我 们 分 析 一 下 它 到 底 保存 了 哪些 数据 。 





源码 : TextView#onSavelnstanceState 


@Override 

public Parcelable onSavelInstanceState() { 
Parcelable superState = super.onSaveInstanceState()/; 
// Save state if we are forced to 


boolean save = mFreezesText; 





} 


ss.error = getError(); 
return ss; 

J 

return superState; 


} 








从 上 述 源码 可 以 很 容易 看 出 ，TextView 保 存 了 自己 的 文本 选中 状态 
和 文本 内 容 ， 并 且 通 过 查看 其 onRestoreInstanceState 方 法 的 源码 ， 可 以 
发 现 它 的 确 恢复 了 这 些 数据 ， 有 具体 源码 就 不 再 贴 出 了 ， 读 者 可 以 去 看 看 
源码 。 下 面 我 们 看 一 个 实际 的 例子 ， 来 对 比 一 下 Activity 正 党 终止 和 噶 
第 终止 的 不 同 ， 同 时 验证 系统 的 数据 恢复 能 力 。 为 了 方便 ， 我 们 选择 旋 
转 屏 幕 来 异常 终止 Activity， 如 图 1-4 所 示 。 
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图 1-4 Activity 旋 转 屏 幕后 数据 的 保存 和 恢复 


通过 图 1-4 可 以 看 出 ， 在 我 们 选择 屏 磊 以 后 ，Activity 科 销毁 后 重新 
创建 ， 我 们 输入 的 文本 “这 是 测试 文本 ”被 正确 地 还 原 ， 这 说 明 系 统 的确 
能 够 自动 地 做 一 些 View 层 次 结构 方面 的 数据 存储 和 恢复 。 下 和 面 再 用 一 个 
例子 ， 来 验证 我 们 目 己 做 数据 存储 和 恢复 的 情况 ， 代 人 码 如 下 : 


@Override 


protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_main); 
if (savedInstanceState != null) { 
String test = savedInstanceState.getString("extra 


Log.d(TAG, "[onCreate]restore extra_test:" + test) 


} 

@Override 

protected void onSaveInstanceState(Bundle outState) { 
super .onSaveInstanceState(outState); 
Log.d(TAG, "onSaveInstanceState"); 
outState.putString("extra_test","test"); 

} 

@Override 

protected void onRestoreInstanceState(Bundle savedInstanceSta 
super .onRestoreInstanceState(savedInstanceState) ; 
String test = savedInstanceState.getString("extra_test"); 


Log.d(TAG, "[onRestoreInstanceState]restore extra_test:" + 


上 面 的 代码 很 简单 ， 首 先 我 们 在 onSaveInstanceState 中 存储 一 个 字 


符 串 ， 然 后 当 Activity 被 销毁 并 重新 创建 后 ， 我 们 再 去 获取 之 前 存储 的 
字符 串 。 接 收 的 位 置 可 以 选择 onRestoreInstanceState 或 者 onCreate， 二 者 
的 区 别 是 ，onRestoreInstanceState 一 旦 被 调用 ， 其 参数 Bundle 
savedInstanceState 一 定 是 有 值 的 ， 我 们 不 用 额外 地 判断 是 否 为 空 ;但 是 
onCreate 不 行 ，onCreate 如 果 是 正常 启动 的 话 ， 其 参数 Bundle 


savedInstanceState 为 null， 所 以 必须 要 额外 判断 。 这 两 个 方法 我 们 选择 任 
意 一 个 都 可 以 进行 数据 恢复 ， 但 是 官方 文档 的 建议 是 采用 
onRestoreInstanceState 去 恢复 数据 。 下 面 我 们 看 一 下 运行 的 日 志 ， 如 图 
1-5 所 示 。 








Level PID TID Application Tag Text 
8534 8534 com.ryg.chapter_1 MainActivity onPause 
6534 6534 com.ryg.chapter_1 MainActivity onSaveInstanceState 
6534 8534 com.ryg.chapter_1 MainActivity onStop 
4 8534 com.ryg.chapter_1 MainActivity onDestroy 


8534 8534 com.ryg.chapter_1 MainActivity [onCreate]restore extra_test:test 








6534 8534 com.ryg.chapter_1 MainActivity [onRestoreInstanceState]restore extra_test:test 


图 1-5 系统 日 志 


如 图 1-5 所 示 ，Activity 被 销毁 了 以 后 调用 了 onSaveInstanceState 来 保 
存 数据 ， 重 新 创建 以 后 在 onCreate 和 onRestoreInstanceState 中 都 能 够 正确 
地 恢复 我 们 之 前 存储 的 字符 串 。 这 个 例子 很 好 地 证 明了 上 面 我 们 的 分 析 
结论 。 针 对 onSavelInstanceState 方 法 还 有 一 点 需要 说 明 ， 那 就 是 系统 只 
会 在 Activity 即 将 被 销毁 并 且 有 机 会 重新 显示 的 情况 下 才 会 去 调用 它 。 
考虑 这 么 一 种 情况 ， 当 Activity 正 常 销 毁 的 时 候 ， 系 统 不 会 调用 
onSaveInstanceState， 因 为 被 销毁 的 Activity 不 可 能 再 次 被 显示 。 这 人 句 话 
不 好 理解 ， 但 是 我 们 可 以 对 比 一 下 旋转 屏幕 所 造成 的 Activity 异 香 销 
筑 ， 这 个 过 程 和 正常 停止 Activity 是 不 一 样 的 ， 因 为 旋转 屏幕 后 ， 
Activity 被 销毁 的 同时 会 立刻 创建 新 的 Activity 实 例 ， 这 个 时 候 Activity 有 
机 会 再 次 立刻 展示 ， 所 以 系统 要 进行 数据 存储 。 这 里 可 以 简单 地 这 人 么 理 
解 ， 系 统 只 在 Activity 异 常 终止 的 时 候 才 会 调用 onSaveInstanceState 和 
onRestoreInstanceState 来 存储 和 恢复 数据 ， 其 他 情况 不 会 触发 这 个 过 


程 。 


2. 情况 2: 资源 内 存 不 足 导致 低 优先 级 的 Activity 裤 杀 和 死 





这 种 情况 我 们 不 好 模拟 ， 但 是 其 数据 存储 和 恢复 过 程 和 情况 1 完全 
一 致 。 这 里 我 们 描述 一 下 Activity 的 优先 级 情况 。Activity 按 照 优先 级 从 
高 到 低 ， 可 以 分 为 如 下 三 种 : 


(1) 前 台 Activity 一 一 正在 和 用 户 交 互 的 Activity， 优 先 级 最 高 。 








(2) 可 见 但 非 前 台 Activity 一 一 比如 Activity 中 弹出 了 一 个 对 话 框 ， 
导致 Activity 可 见 但 是 位 于 后 台 无 法 和 用 户 直 接 交 互 。 








(3) 后 台 Activity 
优先 级 最 低 。 


已 经 被 暂停 的 Activity， 比 如 执行 了 onStop， 





当 系 统 内 存 不 足 时 ， 系 统 束 会 按照 上 述 优先 级 去 杀 死 目标 Activity 
所 在 的 进程 ， 并 在 后 续 通 过 onSaveInstanceState 和 onRestoreInstanceState 
来 存储 和 恢复 数 数据 。 如 果 一 个 进程 中 没有 四 大 组 件 在 执行 ， 那 么 这 个 
进程 将 很 快 被 系统 杀 死 ， 因 此 ， 一 些 后 台 工 作 不 适合 脱离 四 大 组 件 而 独 
自 运行 在 后 台中 ， 这 样 进程 很 容易 被 杀 死 。 比 较 好 的 方法 是 将 后 台 工 作 
放 入 Service 中 从 而 保证 进程 有 一 定 的 优先 级 ， 这 样 就 不 会 轻易 地 被 系统 
ARK 





上 面 分 析 了 系统 的 数据 存储 和 恢复 机 制 ， 我 们 知道 ， 当 系统 配置 发 
生 改 变 后 ，Activity 会 被 重新 创建 ， 那 么 有 没有 办 法 不 重新 创建 呢 ? 答 
案 是 有 的 ， 接 下 来 我 们 就 来 分 析 这 个 问题 。 系 统 配置 中 有 很 多 内 容 ， 如 
果 当 某 项 内 容 发 生 改 变 后 ， 我 们 不 想 系 统 重 新 创建 Activity， 可 以 给 
Activity 指 定 configChanges 属 性 。 比 如 不 想 让 Activity 在 屏幕 旋转 的 时 候 
重新 创建 ， 就 可 以 给 configChanges 属 性 添加 orientation 这 个 值 ， 如 下 所 
示 。 








android:configChanges="orientation" 
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android:configChanges="orientation|keyboardHidden"。 系 统 配置 中 所 含 的 
项 目 是 非常 多 的 ， 下 面 介 绍 每 个 项 目的 含义 ， 如 表 1-1 所 示 。 





表 1-1 configChanges 的 项 目 和 含义 


含义 

SIM 卡 唯 一 标识 IMSI (国际 移动 用 户 识 别 码 ) 中 的 国家 代码 ， 由 三 位 数字 组 成 ， 中 国 为 460。 此 项 
标识 mee 代码 发 生 了 改变 

SIM 卡 叭 一 标识 IMSI (国际 移动 用 户 识别 码 ) 中 的 运营 商 代码 ， 由 两 位 数字 组 成 ， 中 国 移动 TD 系 
统 为 00， 中 国联 通 为 01， 中 国电 信 为 03 。 此 项 标识 mne 发 生 改 变 
locale 设备 的 本 地 位 置 发 生 了 改变 ， 一 般 指 切换 了 系统 语言 
touchscreen 触摸 屏 发 生 了 改变 ， 这 个 很 费解 ， 正 常情 况 下 无 法 发 生 ， 可 以 忽略 它 
keyboard 键盘 类 型 发 生 了 改变 ， 比 如 用 户 使 用 了 外 插 键 盘 
keyboardHidden 键盘 的 可 访问 性 发 生 了 改变 ， 比 如 用 户 调 出 了 键盘 
navigation 系统 导航 方式 发 生 了 改变 ， 比 如 采用 了 轨迹 球 导航 ， 这 个 有 点 费解 ， 很 难 发 生 ， 可 以 忽略 它 
screenLayout 屏幕 布局 发 生 了 改变 ， 很 可 能 是 用 户 激活 了 另外 一 个 显示 设备 
fontScale 系统 字体 缩放 比例 发 生 了 改变 ， 比 如 用 户 选 择 了 一 个 新 字号 
uiMode 用 户 界面 模式 发 生 了 改变 ， 比 如 是 否 开启 了 夜间 模式 (API 8 新 添加 ) 
orientation 屏幕 方向 发 生 了 改变 ， 这 个 是 最 常用 的 ， 比 如 旋转 了 手机 屏幕 
当 屏 幕 的 尺寸 信息 发 生 了 改变 ， 当 旋转 设备 屏幕 时 ， 屏 幕 尺 寸 会 发 生变 化 ， 这 个 选项 比较 特殊 ， 它 
screenSize 和 编译 选项 有 关 ， 当 编译 选项 中 的 minSdkVersion 和 targetSdkVersion 均 低 于 13 时 ， 此 选项 不 会 导致 
Activity 重启 ， 否 则 会 导致 Activity 重启 (‘API 13 新 添加 ) 

设备 的 物理 屏幕 尺寸 发 生 改 变 ， 这 个 项 目 和 屏幕 的 方向 没关系 ， 仅 仅 表 示 在 实际 的 物理 屏幕 的 尺寸 
改变 的 时 候 发 生 ， 比 如 用 户 切 换 到 了 外 部 的 显示 设备 ， 这 个 选项 和 screenSize 一 样 ， 当 编译 选项 中 的 
minSdkVersion fil targetSdkVersion 均 低 于 13 时 ， 此 选项 不 会 导致 Activity 重启 ， 否 则 会 导致 Activity 
重启 (API 13 新 添加 ) 

当 布 局 方向 发 生变 化 ,这 个 属性 用 的 比较 少 , 正常 情况 下 无 须 修 改 布局 的 layoutDirection 属性 CAPI 
17 新 添加 ) 






































smallestScreenSize 








layoutDirection 





从 表 1-1 可 以 知道 ， 如 果 我 们 没有 在 Activity 的 configChanges 属 性 中 
指定 该 选项 的 话 ， 当 配置 发 生 改 变 后 就 会 导致 Activity 重 新 创建 。 上 面 
表格 中 的 项 目 很 多 ， 但 是 我 们 第 用 的 只 有 locale、orientation 和 
keyboardHidden 这 三 个 选项 ， 其 他 很 少 使 用 。 需 要 注意 的 是 screenSize 和 
smallestScreenSize， 它 们 两 个 比较 特殊 ， 它 们 的 行为 和 编译 选项 有 关 ， 
但 和 运行 环境 无 关 。 下 面 我 们 再 看 一 个 demo， 看 看 当 我 们 指定 了 
configChanges 属 性 后 ，Activity 是 否 真 的 不 会 重新 创建 了 。 我 们 所 要 修 
改 的 代码 很 简单 ， 只 需要 在 AndroidMenifest.xml 中 加 入 Activity 的 声明 即 
可 ， 代 码 如 下 : 








<uses-sdk 
android:minSdkVersion="8" 
android: targetSdkVersion="19" /> 
<activity 
android: name="com.ryg.chapter_1.MainActivity" 
android: configChanges="orientation|screenSize" 
android: label="@string/app_name" > 
<intent-filter> 
<action android:name="android.intent.action.MAIN" 
<category android:name="android.intent.category.L 
</intent-filter> 
</activity> 
@Override 
public void onConfigurationChanged(Configuration newConfig) { 
super .onConfigurationChanged(newConfig) ; 


Log.d(TAG, "onConfigurationChanged, newOrientation:" + newC 


需要 说 明 的 是 ， 由 于 编译 时 笔者 指定 的 minSdkVersion 和 
targetSdkVersion 有 一 个 大 于 13， 上 所 以 为 了 防止 旋转 屏幕 时 Activity 重 
启 ， 除 了 orientation， 我 们 还 要 加 上 screenSize， 原 因 在 上 面 的 表格 里 已 
经 说 明了 。 其 他 代码 还 是 不 变 ， 运 行 后 看 看 log， 如 图 1-6 所 示 。 








Level PID TID = Application Tag Text 

D 3565 3565 com.ryg.chapter_1 MainActivity onConfigurationChanged, newOrientation:2 
D 3565 3565 com.ryg.chapter_l1 MainActivity onConfigurationChanged, newOrientation:1 
D 3565 3565 com.ryg.chapter_1 MainActivity onConfigurationChanged, newOrientation:2 








图 1-6 系统 日 志 





由 上 面 的 日 志 可 见 ，Activity 的 确 没 有 重新 创建 ， 并 且 也 没有 调用 
onSaveInstanceState 和 onRestoreInstanceState 来 存储 和 恢复 数据 ， 取 而 代 
之 的 是 系统 调用 了 Activity 的 onConfigurationChanged 方 法 ， 这 个 时 候 我 
们 束 可 以 做 一 些 自己 的 特殊 处 理 了 。 





1.2 ”Activity 的 启动 模式 


上 一 节 介 绍 了 Activity 在 标准 情况 下 和 异常 情况 下 的 生命 周期 ， 我 
们 对 Activity 的 生命 周期 应 该 有 了 深入 的 了 解 。 除 了 Activity 的 生命 周期 
外 ，Activity 的 启动 模式 也 是 一 个 难点 ， 原 因 是 形形色色 的 启动 模式 和 
标志 位 实在 是 太 容 易 被 混淆 了 ， 但 是 Activity 作 为 四 大 组 件 之 首 ， 它 的 
的 确 确 非 常 重要 ， 有 时 候 为 了 满足 项 目的 特殊 需求 ， 就 必须 使 用 
Activity 的 启动 模式 ， 所 以 我 们 必须 要 搞 清楚 它 的 启动 模式 和 标志 位 ， 


本 节 将 会 一 一 介绍 。 














1.2.1 _ Activity 的 LaunchMode 


自 先 说 一 下 Activity 为 什么 需要 启动 模式 。 我 们 知道 ， 在 默认 情况 
下 ， 当 我 们 多 次 启动 同一 个 Activity 的 时 候 ， 系 统 会 创建 多 个 实例 并 把 
它们 一 一 放 入 任务 栈 中 ， 当 我 们 单 击 back 键 ， 会 发 现 这 些 Activity 会 一 一 
回 退 。 任 务 栈 是 一 种 “后 进 先 出 ”的 栈 结构 ， 这 个 比较 好 理解 ， 每 按 一 下 
back 键 就 会 有 一 个 Activity 出 栈 ， 直 到 栈 空 为 止 ， 当 栈 中 无 任何 Activity 
的 时 候 ， 系 统 就 会 回收 这 个 任务 栈 。 关 于 任务 栈 的 系统 工作 原理 ， 这 里 
暂时 不 做 说 明 ， 在 后 续 章 节 会 专门 介绍 任务 栈 。 知 道 了 Activity 的 默认 
启动 模式 以 后 ， 我 们 可 能 就 会 发 现 一 个 问题 ， 多 次 启动 同一 个 
Activity， 系 统 重复 创建 多 个 实例 ， 这 样 不 是 很 傻 吗 ? 这 样 的 确 有 点 
傻 ，Android 在 设计 的 时 候 不 可 能 不 考虑 到 这 个 问题 ， 所 以 它 提供 了 局 
动 模式 来 修改 系统 的 默认 行为 。 目 前 有 四 种 启动 模式 : standard, 
singleTop、singleTask 和 singleInstance， 下 面 先 介绍 各 种 启动 模式 的 含 


X: 





(1) standard: 标准 模式 ， C a aac 每 次 启动 一 个 
Activity 都 会 重新 创建 一 个 新 的 实例 ， 不 管 这 个 实例 是 否 已 经 存在 。 被 
创建 的 实例 的 生命 周期 符合 典型 情况 下 Activity 的 生命 周期 ， 如 上 节 描 
述 ， 它 的 onCreate、onStart、onResume 都 会 被 调用 。 这 是 一 种 典型 的 多 
实例 实现 ， 一 个 任务 栈 中 可 以 有 多 个 实例 ， 每 个 实例 也 可 以 属于 不 同 的 
任务 栈 。 在 这 种 模式 下 ， 谁 启动 了 这 个 Activity， 那 么 这 个 Activity 残 运 
行 在 启动 它 的 那个 Activity 所 在 的 栈 中 。 比 如 Activity ”A 启动 了 Activity 
BB 是 标准 模式 ) ， 那 么 B 束 会 进入 到 A 所 在 的 栈 中 。 不 知道 读者 是 否 
注意 到 ， 当 我 们 用 ApplicationContext 去 启动 standard 模 式 的 Activity 的 时 
候 会 报错 ， 错 误 如 下 : 








E/AndroidRuntime(674): android.util.AndroidRuntimeException: 


相信 这 人 句 话 读者 一 定 不 陌生 ， 这 是 因为 standard 模 式 的 Activity 默 认 
会 进入 局 动 它 的 Activity 所 属 的 任务 栈 中 ， 但 是 由 于 非 Activity 类 型 的 
Context (如 ApplicationContext〉 并 没有 所 谓 的 任务 栈 ， 所 以 这 就 有 问题 
了 。 解 决 这 个 问题 的 方法 是 为 竺 局 动 Activity 指 定 
FLAG_ACTIVITY_NEW_TASK 标 记 位 ， 这 样 启动 的 时 候 就 会 为 它 创建 
一 个 新 的 任务 栈 ， 这 个 时 候 待 启动 Activity 实 际 上 是 以 singleTask 模 式 启 
动 的 ， 读 者 可 以 仔细 体会 。 


(2) singleTop: 栈 顶 复 用 模式 。 在 这 种 模式 下 ， 如 果 新 Activity 已 
经 位 于 任务 栈 的 栈 顶 ， 那 么 此 Activity 不 会 被 重新 创建 ， 同 时 它 的 
onNewntent 方 法 会 被 回调 ， 通 过 此 方法 的 参数 我 们 可 以 取出 当前 请 求 
的 信息 。 需 要 注意 的 是 ， 这 个 Activity 的 onCreate、onStart 不 会 被 系统 调 
用 ， 因 为 它 并 没有 发 生 改 变 。 如 果 新 Activity 的 实例 已 存在 但 不 是 位 于 








栈 顶 ， 那 么 新 Activity 仍 然 会 重新 重建 。 举 个 例子 ， 假 设 目 前 栈 内 的 情 
况 为 ABCD， 其 中 ABCD 为 四 个 Activity，A 位 于 栈 底 ，D 位 于 栈 顶 ， 这 
个 时 候 假设 要 再 次 启动 D， 如 果 D 的 启动 模式 为 singleTop， 那 么 栈 内 的 
情况 仍然 为 ABCD; 如 采 D 的 局 动 模式 为 standard， 那 么 由 于 D 被 重新 创 
建 ， 导 致 栈 内 的 情况 就 变 为 ABCDD。 








(3) singleTask: 栈 内 复 用 模式 。 这 是 一 种 单 实 例 模 式 ， 在 这 种 模 
式 下 ， 只 要 Activity 在 一 个 栈 中 存在 ， 那 么 多 次 局 动 此 Activity 都 不 会 重 
新 创建 实例 ， 和 singleTop 一 样 ， 系 统 也 会 回调 其 onNewIntent。 具 体 一 
点 ， 当 一 个 具有 singleTask 模 式 的 Activity 请 求 启动 后 ， 比 如 Activity A, 
系统 首先 会 寻找 是 否 存 在 A 想 要 的 任务 栈 ， 如 果 不 存 在 ， 就 重新 创建 一 
个 任务 栈 ， 然 后 创建 A 的 实例 后 把 A 放 到 栈 中 。 如 果 存 在 A 所 需 的 任务 
栈 ， 这 时 要 看 A 是 否 在 栈 中 有 实例 存在 ， 如 果 有 实例 存在 ， 那 么 系统 就 
会 把 A 调 到 栈 顶 并 调用 它 的 onNewIntent 方 法 ， 如 果实 例 不 存在 ， 束 创建 
A 的 实例 并 把 A 压 入 栈 中 。 举 几 个 例子 : 

















比如 目前 任务 栈 S1 中 的 情况 为 ABC， 这 个 时 候 Activity D 以 
singleTask 模 式 请 求 启 动 ， 其 所 需要 的 任务 栈 为 S92， 由 于 S2 和 DD 的 实 
例 均 不 存在 ， 所 以 系统 会 先 创 建 任务 栈 S2， 然 后 再 创建 D 的 实例 并 
将 其 入 栈 到 S2。 

另外 一 种 情况 ， 假 设 D 所 需 的 任务 栈 为 S1， 其 他 情况 如 上 面 例子 1 

所 示 ， 那 么 由 于 S1 已 经 存在 ， 所 以 系统 会 直接 创建 D 的 实例 并 将 其 
入 栈 到 S1。 

如 果 D 所 需 的 任务 栈 为 S1， 并 且 当 前 任务 栈 S1 的 情况 为 ADBC， 根 
据 栈 内 复 用 的 原则 ， 此 时 D 不 会 重新 创建 ， 系 统 会 把 D 切 换 到 栈 顶 

并 调用 其 onNewIntent 方 法 ， 同 时 由 于 singleTask 默 认 具 有 clearTop 的 
效果 ， 会 导致 栈 内 所 有 在 D 上 面 的 Activity 全 部 出 栈 ， 于 是 最 终 S1 中 








的 情况 为 AD。 这 一 点 比较 特殊 ， 在 后 面 还 会 对 此 种 情况 详细 地 分 
析 。 


通过 上 述 3 个 例子 ， 读 者 应 该 能 比较 清晰 地 理解 sngleTask 的 含义 


(4) singleInstance: 单 实例 模式 。 这 是 一 种 加 强 的 singleTask 模 
式 ， 它 除了 具有 singleTask 模 式 的 所 有 特性 外 ， 还 加 强 了 一 点 ， 那 就 是 
县 有 此 种 模式 的 Activity 只 能 单独 地 位 于 一 个 任务 栈 中 ， 换 句 话 说 ， 比 
如 Activity A 是 singleInstance 模 式 ， 当 A 局 动 后 ， 系 统 会 为 它 创 建 一 个 新 
的 任务 栈 ， 然 后 A 独 自在 这 个 新 的 任务 栈 中 ， 由 于 栈 内 复 用 的 特性 ， 后 
续 的 请 求 均 不 会 创建 新 的 Activity， 除 非 这 个 独特 的 任务 栈 被 系统 销毁 
Tg 


上 面 介绍 了 几 种 启动 模式 ， 这 里 需要 指出 一 种 情况 ， 我 们 假设 目前 
有 2 个 任务 栈 ， 前 台 任 务 栈 的 情况 为 AB， 而 后 台 任 务 栈 的 情况 为 CD， 
这 里 假设 CD 的 启动 模式 均 为 singleTask。 现 在 请 求 启动 D， 那 么 整个 后 
台 任 务 栈 都 会 被 切换 到 前 台 ， 这 个 时 候 整 个 后 退 列 表 变 成 了 ABCD。 当 
用 户 按 back 键 的 时 候 ， 列 表 中 的 Activity 会 一 一 出 栈 ， 如 图 1-7 所 示 。 如 
果 不 是 请 求 启 动 D 而 是 启动 C， 那 么 情况 就 不 一 样 了 ， 请 看 图 1-8， 有 具体 
原因 在 本 节 后 面 会 再 进行 详细 分 析 。 








: SingleTask 模 式 | 
后 台 任 务 栈 


\enstusncencsenendecansasescessne 


图 1-7 任务 栈 示例 1 
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图 1-8 任务 栈 示例 2 


另外 一 个 问题 是 ， 在 singleTask 启 动 模式 中 ， 多 次 提 到 某 个 Activity 
所 需 的 任务 栈 ， 什 么 是 Activity 所 需要 的 任务 栈 呢 ? 这 要 从 一 个 参数 说 
起 : TaskAffinity， 可 以 翻译 为 任务 相关 性 。 这 个 参数 标识 了 一 个 
Activity 所 需要 的 任务 栈 的 名 字 ， 默 认 情 况 下 ， 所 有 Activity 所 需 的 任务 
栈 的 名 字 为 应 用 的 包 名 。 当 然 ， 我 们 可 以 为 每 个 Activity 都 单独 指定 
TaskAffinity 属 性 ， 这 个 属性 值 必须 不 能 和 包 名 相同 ， 人 否则 残 相 当 于 没有 
指定 。TaskAffinity 属 性 主要 和 singleTask 启 动 模式 或 者 
allowTaskReparenting 属 性 配对 使 用 ， 在 其 他 情况 下 没有 意义 。 男 外 ， 任 
务 栈 分 为 前 台 任 务 栈 和 后 台 任 务 栈 ， 后 台 任 务 栈 中 的 Activity 位 于 暂停 
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当 TaskAffinity 和 singleTask 启 动 模式 配对 使 用 的 时 候 ， 它 是 具有 该 
模式 的 Activity 的 目前 任务 栈 的 名 字 ， 待 启动 的 Activity 会 运行 在 名 字 和 
TaskAffinity 相 同 的 任务 栈 中 。 


当 TaskAffinity 和 allowTaskReparenting 结 合 的 时 候 ， 这 种 情况 比较 
复杂 ， 会 产生 特殊 的 效果 。 当 一 个 应 用 A 局 动 了 应 用 B 的 某 个 Activity 
后 ， 如 果 这 个 Activity 的 allowTaskReparenting 属 性 为 true 的 话 ， 那 么 当 应 
用 B 被 启动 后 ， 此 Activity 会 直接 从 应 用 A 的 任务 栈 转 移 到 应 用 B 的 任务 
栈 中 。 这 还 是 很 抽象 ， 再 具体 点 ， 比 如 现在 有 2 个 应 用 A 和 B，A 启 动 了 
B 的 一 个 Activity ”C， 然 后 按 Home 键 回 到 朱 面 ， 然 后 再 单 击 B 的 和 桌面 图 
标 ， 这 个 时 候 并 不 是 启动 了 B 的 主 Activity， 而 是 重新 显示 了 已 经 被 应 用 
A 启动 的 Activity C， 或 者 说 ，C 从 A 的 任务 栈 转移 到 了 B 的 任务 栈 中 。 可 
以 这 么 理解 ， 由 于 A 启动 了 C， 这 个 时 候 C 只 能 运行 在 A 的 任务 栈 中 ， 但 
是 C 属 于 B 应 用 ， 正 常情 况 下 ， 它 的 TaskAffinity 值 肯定 不 可 能 和 A 的 任 
PIHE AKEZA) 。 所 以 ， 当 B 被 启动 后 ，B 会 创建 自己 的 任 
务 栈 ， 这 个 时 候 系 统 发 现 C 原 本 所 想 要 的 任务 栈 已 经 被 创建 了 ， 所 以 就 
把 C 从 A 的 任务 栈 中 转移 过 来 了 。 这 种 情况 读者 可 以 写 个 例子 测试 一 
下 ， 这 里 就 不 做 示例 了 。 




















如 何 给 Activity 指 定 启动 模式 呢 ? 有 两 种 方法 ， 第 一 种 是 通过 
AndroidMenifest 为 Activity 指 定 启动 模式 ， 如 下 所 示 。 


<activity 
android: name="com.ryg.chapter_1.SecondActivity" 
android: configChanges="screenLayout" 


android: LaunchMode="singleTask" 


android: label="@string/app_name" /> 


另 一 种 情况 是 通过 在 Intent 中 设置 标志 位 来 为 Activity 指 定局 动 模 
Ts 比如 : 


Intent intent = new Intent(); 
intent.setClass(MainActivity.this, SecondActivity.class); 
intent.addFlags(Intent .FLAG_ACTIVITY_NEW_TASK) ; 


startActivity(intent); 





这 两 种 方式 都 可 以 为 Activity 指 定 启 动 模式 ， 但 是 二 者 还 是 有 区 别 
的 。 首 先 ， 优 先 级 上 ， 第 二 种 方式 的 优先 级 要 高 于 第 一 种 ， 当 两 种 同时 
存在 时 ， 以 第 二 种 方式 为 准 ; 其 次 ， 上 述 两 种 方式 在 限定 范围 上 有 所 不 
同 ， 比 如 ， 第 一 种 方式 无 法 直接 为 Activity 设 定 
FLAG_ACTIVITY_CLEAR_TOP 标 识 ， 而 第 二 种 方式 无 法 为 Activity 指 
定 singleInstance 模 式 。 





Eou 虽 定 的 各 种 标记 位 ， 人 eee 
。 下 面 通过 一 个 例子 来 体验 启动 模式 的 使 用 效果 。 还 是 前 面 的 例 
ee ] 把 MainActivity 的 局 动 模式 设 为 singleTask， 然 后 重复 局 动 
它 ， 看 看 是 否 会 重复 创建 ， 代 人 码 修 改 如 下 : 














<activity 
android: name="com.ryg.chapter_1.MainActivity" 
android: configChanges="orientation|screenSize" 
android: label="@string/app_name" 
android: LlaunchMode="singleTask" > 


<intent-filter> 


<action android:name="android.intent.action.MAIN" 
<category android:name="android.intent.category.L 
</intent-filter> 
</activity> 
@Override 
protected void onNewIntent(Intent intent) { 
super.onNewIntent(intent); 
Log.d(TAG, "onNewIntent, time=" + intent.getLongExtra("time 
} 
findViewById(R.id.button1).setOnClickListener(new OnClickList 
@Override 
public void onClick(View v) { 
Intent intent = new Intent(); 
intent.setClass(MainActivity.this,MainActivity.cl 
intent.putExtra("time",System.currentTimeMillis()); 


startActivity(intent); 


F); 





根据 上 述 修改 ， 我 们 做 如 下 操作 ， 连 续 单 击 三 次 按钮 启动 3 次 
MainActivity， 算 上 原本 的 MainActvity 的 实例 ， 正 常情 况 下 ， 任 务 栈 中 
应 该 有 4 个 MainActivity 的 实例 ， 但 是 我 们 为 其 指定 了 singleTask 模 式 ， 
现在 来 看 一 看 到 底 有 何不 同 。 


执行 adb shell dumpsys activity €: 


ACTIVITY MANAGER ACTIVITIES (dumpsys activity activities) 


Main stack: 


TaskRecord{41350dc8 #9 A com.ryg.chapter_1} 
Intent { cmp=com.ryg.chapter_1/.MainActivity (has extras 
Hist #1: ActivityRecord{412cc188 com.ryg.chapter_1/.Ma 
Intent { act=android.intent.action.MAIN cat=[android 
© cmp=com.ryg.chapter_1/.MainActivity bnds=[160, 235][240, 335] 
ProcessRecord{411e6898 634:com.ryg.chapter_1/10052} 
TaskRecord{4125abc8 #2 A com.android. launcher} 
Intent { act=android.intent.action.MAIN cat=[android.int 
HOME] f1lg=0x10000000 
m.android.launcher/com.android.launcher2.Launcher } 
Hist #0: ActivityRecord{412381f8 com.android.launcher/ 
launcher2.Launcher } 
Intent { act=android.intent.action.MAIN cat=[android 
category.HOME] flg=0x1000 
p=com.android.launcher/com.android.launcher2.Launcher } 
ProcessRecord{411d24c8 214:com.android.launcher/1001 
Running activities (most recent first): 
TaskRecord{41350dc8 #9 A com.ryg.chapter_1} 
Run #1: ActivityRecord{412cc188 com.ryg.chapter_1/.Mal 
TaskRecord{4125abc8 #2 A com.android. launcher } 
Run #0: ActivityRecord{412381f8 com.android.launcher/c 
launcher2.Launcher } 
mResumedActivity: ActivityRecord{412cc188 com.ryg.chapter_ 
mFocusedActivity: ActivityRecord{412cc188 com.ryg.chapter_ 
Recent tasks: 
* Recent #0: TaskRecord{41350dc8 #9 A com.ryg.chapter_1} 


* Recent #1: TaskRecord{4125abc8 #2 A com.android. launcher 


* Recent #2: TaskRecord{412b60a0 #5 A com.estrongs.android 


InstallMonitorActivity} 


从 上 面 导出 的 Activity 信 息 可 以 看 出 ， 尽 管 司 动 了 4 次 MainActivity， 
但 是 它 始 终 只 有 一 个 实例 在 任务 栈 中 ， 从 图 1-9 的 log 可 以 看 出 ，Activity 
的 确 没有 重新 创建 ， 只 是 暂停 了 一 下 ， 然 后 调用 了 onNewIntent， 接 着 
调用 onResume 就 又 继续 了 。 











Level PID TID Application Tag Text 

D 755 755 com.ryg.chapter_1 MainActivity onPause 

D 755 755 com.ryg.chapter_1 MainActivity onNewIntent, time=1422898165307 
D 755 755 com.ryg.chapter_1 MainActivity onResume 

D 755 755 com.ryg.chapter 1 MainActivity onPause 

D 755 755 com.ryg.chapter_1 MainActivity onNewIntent, time=1422898166173 
D 755 755 com.ryg.chapter_1 MainActivity onResume 

D 755 755 com.ryg.chapter_1 MainActivity onPause 

D 755 755 com.ryg.chapter_1 MainActivity onNewIntent, time=1422898167429 
D 755 755 com.ryg.chapter 1 MainActivity onResume 


图 1-9 系统 日 志 


现在 我 们 去 挥 singleTask， 再 来 对 比 一 下 ， 还 是 同样 的 操作 ， 单 击 
三 次 按钮 启动 MainActivity 三 次 。 





执行 adb shell dumpsys activity 命 令 : 


ACTIVITY MANAGER ACTIVITIES (dumpsys activity activities) 
Main stack: 
TaskRecord{41325370 #17 A com.ryg.chapter_1} 
Intent { act=android.intent.action.MAIN cat=[android.int 
LAUNCHER] flg=0x100000 
p=com.ryg.chapter_1/.MainActivity } 
Hist #4: ActivityRecord{41236968 com.ryg.chapter_1/.Ma 


Intent { cmp=com.ryg.chapter_1/.MainActivity (has ex 


ProcessRecord{411e6898 803:com.ryg.chapter_1/10052} 
Hist #3: ActivityRecord{411f4b30 com.ryg.chapter_1/.Ma 
Intent { cmp=com.ryg.chapter_1/.MainActivity (has ex 
ProcessRecord{411e6898 803:com.ryg.chapter_1/10052} 
Hist #2: ActivityRecord{411edcb8 com.ryg.chapter_1/.Ma 
Intent { cmp=com.ryg.chapter_1/.MainActivity (has ex 
ProcessRecord{411e6898 803:com.ryg.chapter_1/10052} 
Hist #1: ActivityRecord{411e7588 com.ryg.chapter_1/.Ma 
Intent { act=android.intent.action.MAIN cat=[android 
LAUNCHER] flg=0x10 
© cmp=com.ryg.chapter_1/.MainActivity } 
ProcessRecord{411e6898 803:com.ryg.chapter_1/10052} 
TaskRecord{4125abc8 #2 A com.android. launcher } 
Intent { act=android.intent.action.MAIN cat=[android.int 
HOME] flg=0x10000000 c 
m.android.launcher/com.android.launcher2.Launcher } 
Hist #0: ActivityRecord{412381f8 com.android.launcher/ 
launcher2.Launcher } 
Intent { act=android.intent.action.MAIN cat=[android 
gory.HOME] flg=0x100000 
p=com. android. launcher/com.android.launcher2.Launcher } 
ProcessRecord{411d24c8 214:com.android.launcher/1001 
Running activities (most recent first): 
TaskRecord{41325370 #17 A com.ryg.chapter_1} 
Run #4: ActivityRecord{41236968 com.ryg.chapter_1/.Mai 
Run #3: ActivityRecord{411f4b30 com.ryg.chapter_1/.Mai 


Run #2: ActivityRecord{411edcb8 com.ryg.chapter_1/.Mai 


Run #1: ActivityRecord{411e7588 com.ryg.chapter_1/.Mai 
TaskRecord{4125abc8 #2 A com.android. launcher } 
Run #0: ActivityRecord{412381f8 com.android.launcher/c 
launcher2.Launcher } 
mResumedActivity: ActivityRecord{41236968 com.ryg.chapter_ 
tivity} 
mFocusedActivity: ActivityRecord{41236968 com.ryg.chapter_ 
tivity} 
Recent tasks: 
* Recent #0: TaskRecord{41325370 #17 A com.ryg.chapter_1} 
* Recent #1: TaskRecord{4125abc8 #2 A com.android. launcher 
* Recent #2: TaskRecord{412c8d58 #16 A com.estrongs.androi 


InstallMonitorActivity} 


上 面 的 导出 信息 很 多 ， 我 们 可 以 有 选择 地 看 ， 比 如 就 看 Running 
activities (most recent first) 这 一 块 ， 如 下 所 示 。 


Running activities (most recent first): 

TaskRecord{41325370 #17 A com.ryg.chapter_1} 
Run #4: ActivityRecord{41236968 com.ryg.chapter_1/.Mai 
Run #3: ActivityRecord{411f4b30 com.ryg.chapter_1/.Mai 
Run #2: ActivityRecord{411edcb8 com.ryg.chapter_1/.Mai 
Run #1: ActivityRecord{411e7588 com.ryg.chapter_1/.Mai 

TaskRecord{4125abc8 #2 A com.android. launcher } 
Run #0: ActivityRecord{412381f8 com.android.launcher/c 


launcher2.Launcher } 








我 们 能 够 得 出 目前 总 共有 2 个 任务 栈 ， 前 台 任 务 栈 的 taskAffinity 值 


为 com.ryg. chapter 1， 它 里 面 有 4 个 Activity， 后 人 台 任 务 栈 的 taskAffinity 
值 为 com.android.launcher， 它 里 面 有 1 个 Activity， 这 个 Activity 丈 是 条 
面 。 通 过 这 种 方式 来 分 析 任务 栈 信息 惑 清 晰 多 了 。 








从 上 面 的 导出 信息 中 可 以 看 到 ， 在 任务 栈 中 有 4 个 MainActivity， 这 
也 就 验证 了 Activity 的 启动 模式 的 工作 方式 。 


上 述 四 种 启动 模式 ，standard 和 singleTop 都 比较 好 理解 ， 
singleInstance 由 于 其 特殊 性 也 好 理解 ， 但 是 关于 singleTask 有 一 种 情况 需 
要 再 说 明 一 下 。 如 图 1-7 所 示 ， 如 果 在 Activity B 中 请 求 的 不 是 D 而 是 C， 
那么 情况 如 何 呢 ? 这 里 可 以 告诉 读者 的 是 ， 任 务 栈 列表 变 成 了 ABC， 是 
不 是 很 奇怪 呢 ? Activity DD 被 直接 出 栈 了 。 下 面 我 们 再 用 实例 验证 看 看 
是 不 是 这 样 。 站 先 ， 还 是 使 用 上 面 的 代码 ， 但 是 我 们 做 一 下 修改 : 








<activity 
android:name="com.ryg.chapter_1.MainActivity" 
android:configChanges="orientation|screenSize" 
android: Llabel="@string/app_name" 
android: LlaunchMode="standard" > 
<intent-filter> 
<action android:name="android.intent.action.MAIN" 
<category android:name="android.intent.category.L 
</intent-filter> 
</activity> 
<activity 
android: name="com.ryg.chapter_1.SecondActivity" 
android: configChanges="screenLayout" 


android: label="@string/app_name" 


android: taskAffinity="com.ryg.taski" 
android: LaunchMode="singleTask" /> 
<activity 
android: name="com.ryg.chapter_1.ThirdActivity" 
android: configChanges="screenLayout" 
android: taskAffinity="com.ryg.task1i" 
android: label="@string/app_name" 


android: LaunchMode="singleTask" /> 


我 们 将 SecondActivity 和 ThirdActivity 都 设 成 singleTask 并 指定 它们 的 
taskAffinity 属 性 为 “com.ryg.task1”， 注 意 这 个 taskAffinity 属 性 的 值 为 字 
符 串 ， 且 中 间 必 须 含 有 包 名 分 隔 符 “.”。 然 后 做 如 下 操作 ， 在 
MainActivity 中 单 击 按钮 启动 SecondActivity， 在 SecondActivity 中 单 击 按 
钮 启动 ThirdActivity， 在 ThirdActivity 中 单 击 按钮 又 启动 MainActivity， 
最 后 再 在 MainActivity 中 单 击 按钮 启动 SecondActivity， 现 在 按 back 键 ， 
然后 看 到 的 是 哪个 Activity? 答案 是 回 到 桌面 。 是 不 是 有 点 换 不 到 头脑 
T? 没关系 ， 接 下 来 我 们 分 析 这 个 问题 。 











首先 ， 从 理论 上 分 析 这 个 问题 ， 先 假设 MainActivity 为 A， 
SecondActivity 为 B，ThirdActivity 为 C。 我 们 知道 A 为 standard 模 式 ， 按 照 
规定 ，A 的 taskAffinity 值 继承 和 目 Application 的 taskAffinity， 而 Application 
默认 taskAffinity 为 包 名 ， 所 以 A 的 taskAffinity 为 包 名 。 由 于 我 们 在 XML 
中 为 B 和 C 指 定 了 taskAffinity 和 启动 模式 ， 所 以 B 和 C 是 singleTask 模 式 且 
有 相同 的 taskAffinity 值 “com.ryg.task1”。 人 A 启动 B 的 时 候 ， 按 照 singleTask 
的 规则 ， 这 个 时 候 需 要 为 B 重 新 创建 一 个 任务 栈 “com.ryg.task1”。B 再 局 
动 C， 按 照 singleTask 的 规则 ， 由 于 C 所 需 的 任务 栈 (和 B 为 同一 任务 
R) 已 经 被 B 创 建 ， 所 以 无 有 顷 再 创建 新 的 任务 栈 ， 这 个 时 候 系统 只 是 创 


建 C 的 实例 后 将 C 入 栈 了 。 接 着 C 再 启动 A，A 是 standard 模 式 ， 所 以 系统 
会 为 它 创 建 一 个 新 的 实例 并 将 到 加 到 启动 它 的 那个 Activity 的 任务 栈 ， 

由 于 是 C 启 动 了 A， 所 以 A 会 进入 C 的 任务 栈 中 并 位 于 栈 顶 。 这 个 时 候 已 
经 有 两 个 任务 栈 了 ， 一 个 是 名 字 为 包 名 的 任务 栈 ， 里 面 只 有 A， 男 一 个 
是 名 字 为 “com.ryg.task1” 的 任务 栈 ， 里 面 的 Activity 为 BCA。 接 下 来 ，A 
再 启动 B， 由 于 B 是 singleTask，B 需 要 回 到 任务 栈 的 栈 项 ， 由 于 栈 的 工 
作 模 式 为 “后 进 先 出 *”，B 想 要 回 到 栈 项 ， 只 能 是 CA 出 栈 。 所 以 ， 到 这 里 
就 很 好 理解 了 ， 如 果 再 按 back 键 ，B 就 出 栈 了 ，B 所 在 的 任务 栈 已 经 不 
存在 了 ， 这 个 时 候 只 能 是 回 到 后 台 任 务 栈 并 把 A 显示 出 来 。 注 意 这 个 A 
是 后 台 任 务 栈 的 A， 不 是 “com.ryg.task1” 任 务 栈 的 A， 接 着 再 继续 back,， 
就 回 到 加 面 了 。 分 析 到 这 里 ， 我 们 得 出 一 条 结论 ，singleTask 模 式 的 
Activity 切 换 到 栈 顶 会 导致 在 它 之 上 的 栈 内 的 Activity 出 栈 。 








接着 我 们 在 实践 中 再 次 验证 这 个 问题 ， 还 是 采用 dumpsys 命 令 。 我 
们 省 略 中 间 的 过 程 ， 直 接 看 C 启 动 A 的 那个 状态 ， 执 行 adb shell dumpsys 
activity 命 令 ， 日 志 如 下 : 





Running activities (most recent first): 
TaskRecord{4132bd90 #12 A com.ryg.task1} 
Run #4: ActivityRecord{4133fd18 com.ryg.chapter_1/.MainAct 
Run #3: ActivityRecord{41349c58 com.ryg.chapter_1/.ThirdAc 
Run #2: ActivityRecord{4132bab0 com.ryg.chapter_1/.SecondA 
TaskRecord{4125a008 #11 A com.ryg.chapter_1} 
Run #1: ActivityRecord{41328c60 com.ryg.chapter_1/.MainAct 
TaskRecord{41256440 #2 A com.android. launcher } 
Run #0: ActivityRecord{41231d30 com.android.launcher/com.a 


er2.Launcher } 





可 以 清楚 地 看 到 有 2 个 任务 栈 ， 第 一 个 〈com.ryg.chapter_ 1) 只 有 
A， 第 二 个 (com.ryg.task1) 有 BCA， 就 如 同 我 们 上 面 分 析 的 那样 ， 然 
后 再 从 A 中 启动 B， 再 看 一 下 日 志 : 


Running activities (most recent first): 
TaskRecord{4132bd90 #12 A com.ryg.task1} 

Run #2: ActivityRecord{4132bab0 com.ryg.chapter_1/.SecondA 
TaskRecord{4125a008 #11 A com.ryg.chapter_1} 

Run #1: ActivityRecord{41328c60 com.ryg.chapter_1/.MainAct 
TaskRecord{41256440 #2 A com.android.launcher } 

Run #0: ActivityRecord{41231d30 com.android.launcher/com.a 


er2.Launcher } 
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了 ， 这 个 时 候 再 按 back 键 ， 任 务 栈 com.ryg.chapter_1 中 的 A 就 显示 出 来 
了 ， 如 果 再 back 就 回 到 提 面 了 。 分 析 到 这 里 ， 相 信 读 者 对 Activity 的 启动 
模式 已 经 有 很 深入 的 理解 了 。 下 面 介绍 Activity 中 常用 的 标志 位 。 


1.2.2 ActivityHJFlags 


Activity 的 Flags 有 很 多 ， 这 里 主要 分 析 一 些 比较 常用 的 标记 位 。 标 
记 位 的 作用 很 多 ， 有 的 标记 位 可 以 设 定 Activity 的 启动 模式 ， 比 如 
FLAG_ACTIVITY NEW_TASK 和 FLAG_ACTIVITY_SINGLE_TOP 等 ; 
还 有 的 标记 位 可 以 影响 Activity 的 运行 状态 ， 比 如 
FLAG_ACTIVITY_CLEAR_TOP 和 
FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS 等 。 下 面 主 要 介绍 几 
个 比较 常用 的 标记 位 ， 剩 下 的 标记 位 读者 可 以 查看 官方 文档 去 了 解 ， 大 











部 分 情况 下 ， 我 们 不 需要 为 Activity 指 定 标记 位 ， 因 此 ， 对 于 标记 位 理 
解 即 可 。 在 使 用 标记 位 的 时 候 ， 要 注意 有 些 标记 位 是 系统 内 部 使 用 的 ， 
应 用 程序 不 需要 去 手动 设置 这 些 标记 位 以 防 出 现 问题 。 








FLAG_ACTIVITY_NEW_TASK 


这 个 标记 位 的 作用 是 为 Activity 指 定 “singleTask” 启 动 模式 ， 其 效果 
和 在 XML 中 指定 该 启动 模式 相同 。 








FLAG_ACTIVITY_SINGLE_TOP 


这 个 标记 位 的 作用 是 为 Activity 指 定 “singleTop” 局 动 模式 ， 其 效果 和 
在 XML 中 指定 该 局 动 模式 相同 。 








FLAG_ACTIVITY_CLEAR_TOP 


有 具有 此 标记 位 的 Activity， 当 它 局 动 时 ， 在 同一 个 任务 栈 中 所 有 位 
于 它 上 面 的 Activity 都 要 出 栈 。 这 个 模式 一 般 需 要 和 
FLAG_ACTIVITY NEW_TASK 配 合 使 用 ， 在 这 种 情况 下 ， 被 启动 
Activity 的 实例 如 果 已 经 存在 ， 那 么 系统 就 会 调用 E 的 onNewIntent。 如 
果 被 启动 的 Activity 采 用 standard 模 式 启动 ， 那 么 它 已 之 上 的 Activity 
都 要 出 栈 ， 系 统 会 创建 新 的 Activity 实 例 并 放 入 栈 顶 。 通 过 1.2.1 节 中 的 
分 析 可 以 知道 ，singleTask 启 动 模式 默认 就 具有 此 标记 位 的 效果 。 





FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS 


具有 这 个 标记 的 Activity 不 会 出 现在 历史 Activity 的 列表 中 ， 当 某 些 
情况 下 我 们 不 希望 用 户 通 过 历史 列表 回 到 我 们 的 Activity 的 时 候 这 个 标 
记 比 较 有 用 。 它 等 同 于 在 XML 中 指定 Activity 的 属性 


android:excludeFromRecents="true" 。 


1.3 IntentFilter 的 匹配 规则 


我 们 知道 ， 局 动 Activity 分 为 两 种 ， 显 式 调 用 和 隐 式 调用 。 二 者 的 
区 别 这 里 就 不 多 说 了 ， 显 式 调 用 需要 明确 地 指定 被 启动 对 象 的 组 件 信 
轧 ， 包 括 包 名 和 类 名 ， 而 隐 式 调用 则 不 需要 明确 指定 组 件 信息 。 原 则 上 
一 个 mntent 不 应 该 既是 显 式 调 用 又 是 隐 式 调用 ， 如 果 二 者 共存 的 话 以 显 
式 调用 为 主 。 显 式 调用 很 简单 ， 这 里 主要 介绍 一 下 隐 式 调用 。 隐 式 调用 
需要 Intent 能 够 匹配 目标 组 件 的 PntentFilter 中 所 设置 的 过 滤 信 息 ， 如 果 不 
匹配 将 无 法 启动 目标 Activity。IntentFilter 中 的 过 滤 信 息 有 action、 
category、data， 下 面 是 一 个 过 滤 规 则 的 示例 : 




















<activity 

android: name="com.ryg.chapter_1.ThirdActivity" 

android: configChanges="screenLayout" 

android: Llabel="@string/app_name" 

android: LaunchMode="singleTask" 

android: taskAffinity="com.ryg.taski"> 

<intent-filter> 
<action android:name="com.ryg.charpter_1.c"/> 
<action android:name="com.ryg.charpter_1.d"/> 
<category android:name="com.ryg.category.c"/> 
<category android:name="com.ryg.category.d"/> 
<category android:name="android.intent.category.D 
<data android:mimeType="text/plain"/> 


</intent-filter> 


</activity> 


为 了 匹配 过 滤 列 表 ， 需 要 同时 匹配 过 滤 列 表 中 的 action、category、 
data 信 息 ， 人 否则 匹配 失败 。 一 个 过 滤 列 表 中 的 action、category 和 data 可 
以 有 多 个 ， 所 有 的 action、category、data 分 别 构成 不 同类 别 ， 同 一 类 别 
的 信息 共同 约束 当前 类 列 的 匹配 过 程 。 只 有 一 个 Intent 同 时 匹配 action 类 
别 、category 类 别 、data 类 别 才 算 完全 匹配 ， 只 有 完全 匹配 才能 成 功 启动 
目标 Activity。 另 外 一 点 ， 一 个 Activity 中 可 以 有 多 个 intent-filter， 一 个 
Intent 只 要 能 匹配 任何 一 组 intent-filter 即 可 成 功 启动 对 应 的 Activity， 如 下 
所 示 。 





<activity android:name="ShareActivity"> 

<!--This activity handles "SEND" actions with text data 

<intent-filter> 
<action android:name="android.intent.action.SEND"/> 
<category android:name="android.intent.category.DEFA 
<data android:mimeType="text/plain"/> 

</intent-filter> 

<!--This activity also handles "SEND" and "SEND _MULTIPLE 

data --> 

<intent-filter> 
<action android:name="android.intent.action.SEND"/> 
<action android:name="android.intent.action.SEND_MUL 
<category android:name="android.intent.category.DEFA 
<data android:mimeType="application/vnd.google.panor 
<data android:mimeType="image/*"/> 


<data android:mimeType="video/*"/> 


</intent-filter> 


</activity> 
下 面 详 细 分 析 各 种 属性 的 匹配 规则 。 
1. action fy JL AC 


action 是 一 个 字符 串 ， 系 统 预定 义 了 一 些 action， 同 时 我 们 也 可 以 在 
应 用 中 定义 自己 的 action。action 的 匹配 规则 是 Pntent 中 的 action 必 须 能 够 
和 过 滤 规 则 中 的 action 匹 配 ， 这 里 说 的 匹配 是 指 action 的 字符 串 值 完全 一 
样 。 一 个 过 滤 规 则 中 可 以 有 多 个 action， 那 么 只 要 Intent 中 的 action 能 够 
和 过 滤 规 则 中 的 任何 一 个 action 相 同 即 可 匹配 成 功 。 针 对 上 面 的 过 滤 规 
则 ， 只 要 我 们 的 Intent 中 action 值 为 “com.ryg.charpter_1.c” 或 
者 “com.ryg.charpter_1.d" 都 能 成 功 匹 配 。 需 要 注意 的 是 ，Intent 中 如 果 没 
有 指定 action， 那 么 匹配 失败 。 总 结 一 下 ，action 的 匹配 要 求 Intent 中 的 
action 存 在 且 必 须 和 过 滤 规 则 中 的 其 中 一 个 action 相 同 ， 这 里 需要 注意 它 
和 category 匹 配 规则 的 不 同 。 另 外 ，action 区 分 大 小 写 ， 大 小 写 不 同 字符 
串 相 同 的 action 会 匹配 失败 。 

















2. category 的 匹配 规则 


category 是 一 个 字符 串 ， 系 统 预 定义 了 一 些 category， 同 时 我 们 也 可 
以 在 应 用 中 定义 自己 的 category。category 的 匹配 规则 和 action 不 同 ， 它 
要 求 Intent 中 如 果 含 有 category， 那 么 所 有 的 category 都 必须 和 过 滤 规 则 
中 的 其 中 一 个 category 相 同 。 换 句 话说，Intent 中 如 果 出 现 了 category， 
不 管 有 几 个 category， 对 于 每 个 category 来 说 ， 它 必须 是 过 滤 规 则 中 已 经 
定义 了 的 category。 当 然 ，Intent 中 可 以 没有 category， 如 果 没 有 category 
的 话 ， 按 照 上 面 的 描述 ， 这 个 Intent 仍 然 可 以 匹配 成 功 。 这 里 要 注意 下 





© AllactionJU ACIS FEM AIA], actionzé 22> Intent "FAA — “action HY 
须 能 够 和 过 小 规则 中 的 某 个 action 相 同 ， 而 category 要 求 Intent 可 以 没有 
category， 但 是 如 果 你 一 旦 有 category， 不 管 有 几 个 ， 每 个 都 要 能 够 和 过 
滤 规 则 中 的 任何 一 个 category 相 同 。 为 了 匹配 前 面 的 过 滤 规 则 中 的 
category， 我 们 可 以 写 出 下 面 的 Intent，intent.addcategory 
(“com.ryg.category.c”) 或 者 Intent，addcategory (“com.ryg.category.d”) 汪 或 
者 不 设置 category。 为 什么 不 设置 category 也 可 以 匹配 昵 ? 原因 是 系统 在 
调用 startActivity 或 者 | 的 时 候 会 默认 为 Intent 加 

上 “android.intent. category. DEFAULT”ix“category, Pr LAX N category xù 
可 以 匹配 前 面 的 过 滤 规 则 中 的 第 三 个 category。 同 时 ， 为 了 我 们 的 
activity 能 够 接收 隐 式 调用 ， 束 必须 在 intent-filter 中 指 

定 “android.intent.category.DEFAULT” 这 个 category， 原 因 刚 才 已 经 说 明 
Te 











3. data 的 匹配 规则 


data 的 匹配 规则 和 action 类 似 ， 如 果 过 滤 规 则 中 定义 了 data， 那 么 
Intent 中 必须 也 要 定义 可 匹配 的 data。 oe ee 我 们 
需要 先 了 解 一 下 data 的 结构 ， 因 为 data 稍 微 有 些 复 





data 的 语法 如 下 所 示 。 


<data android:scheme="string" 
android:host="string" 
android:port="string" 
android:path="string" 
android:pathPattern="string" 


android:pathPrefix="string" 


android:mimeType="string" /> 


data 由 两 部 分 组 成 ，mimeType 和 URI。mimeType 指 媒体 类 型 ， 比 如 
image/jpeg. audio/mpeg4-generic 和 video/* 等 ， 可 以 表示 图 片 、 文 本 、 视 
频 等 不 同 的 媒体 格式 ， 而 URI 中 包含 的 数据 就 比较 多 了 ， 下 面 是 URI 的 
结构 : 


<scheme>://<host>:<port>/[<path>|<pathPrefix>|<pathPatter 
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content://com.example.project:200/folder/subfolder/etc 


http: //www.baidu.com: 80/search/info 





AS EIA BI ABA, BCH, WEIR A fA. AN 
过 下 面 还 是 要 介绍 一 下 每 个 数据 的 含义 。 





Scheme: URI 的 模式 ， 比 如 http、fle、content 等 ， 如 果 URI 中 没有 
指定 scheme， 那 么 整个 URI 的 其 他 参数 无 效 ， 这 也 意味 着 URI 是 无 效 
的 。 











Host: URI 的 主机 名 ， 比 如 www.baidu.com， 如 果 host 未 指定 ， 那 么 
整个 URI 中 的 其 他 参数 无 效 ， 这 也 意味 着 URI 是 无 效 的 。 





Port: URI 中 的 端口 号， 比如 80， 仪 当 URI 中 指定 了 scheme 和 host 参 
数 的 时 候 port 参 数 才 是 有 意义 的 。 


QI 


Path、pathPattern 和 pathPrefix: 这 三 个 参数 表述 路 径 信 息 ， 其 中 


path 表 示 完 整 的 路 径 信息 ; pathPattern 也 表示 完整 的 路 径 信息 ， 但 是 它 
里 面 可 以 包含 通配符 ““”，“*” 表 示 0 个 或 多 个 任意 字符 ， 需 要 注意 的 
是 ， 由 于 正则 表达 式 的 规范 ， 如 果 想 表示 真实 的 字符 串 ， 那 么 “*” 要 和 写 
RA”, VEERA; pathPrefix 表 示 路 径 的 前 绥 信 息 。 





介绍 完 data 的 数据 格式 后 ， 我 们 要 说 一 下 data 的 匹配 规则 了 。 前 面 
说 到 ，data 的 匹配 规则 和 action 类 似 ， 它 也 要 求 Intent 中 必须 含有 data 数 
据 ， 并 且 data 数 据 能 够 完全 匹配 过 滤 规 则 中 的 某 一 个 data. 这 里 的 完全 匹 
配 是 指 过 滤 规 则 中 出 现 的 data 部 分 也 出 现在 了 Intent 中 的 data 中 。 下 面 分 
情况 说 明 。 


(1) 如 下 过 滤 规 则 : 


<intent-filter> 


<data android:mimeType="image/*" /> 


</intent-filter> 


这 种 规则 指定 了 媒体 类 型 为 所 有 类 型 的 图 片 ， 那 么 Intent 中 的 
mimeType 属 性 必须 为 image/*” 才 能 匹配 ， 这 种 情况 下 虽然 过 滤 规 则 没 
有 指定 URI， 但 是 却 有 默认 值 ，URI 的 默认 值 为 content 和 file。 也 就 是 
说 ， 虽 然 没 有 指定 URI， 但 是 Ptent 中 的 URI 部 分 的 Schema 必须 为 content 
或 者 file 才 能 匹配 ， 这 点 是 需要 尤其 注意 的 。 为 了 匹配 〈1) 中 规则 ， 我 
们 可 以 写 出 如 下 示例 : 


intent.setDataAndType(Uri.parse("file://abc"),"image/png"). 


另外 ， 如 果 要 为 Intent 指 定 完整 的 data， 必 须要 调用 setDataAndType 
方法 ， 不 能 先 调用 setData 再 调用 setType， 因 为 这 两 个 方法 彼此 会 清除 对 


方 的 值 ， 这 个 看 源码 就 很 容易 理解 ， 比 如 setData: 


public Intent setData(Uri data) { 
mData = data; 
mType = null; 


return this; 


可 以 发 现 ，setData 会 把 mimeType 置 为 null， 同 理 setType 也 会 把 URI 
置 为 null。 


(2) 如 下 过 滤 规 则 : 


<intent-filter> 


<data android:mimeType="video/mpeg" android:scheme="http 


<data android:mimeType="audio/mpeg" android:scheme="http 
</intent-filter> 
这 种 规则 指定 了 两 组 data 规 则 ， 且 每 个 data 都 指定 了 完整 的 属性 
值 ， 既 有 URI 义 有 mimeType。 为 了 匹配 (2)〉 中 规则 ， 我 们 可 以 写 出 如 
下 示例 : 
intent.setDataAndType(Uri.parse("http://abc"),"video/mpeg" ) 
或 者 
intent. setDataAndType (Uri.parse("http://abc"),"audio/mpeg" ) 


通过 上 面 两 个 示例 ， 读 者 应 该 已 经 明白 了 data 的 匹配 规则 ， 关 于 





data 还 有 一 个 特殊 情况 需要 说 明 下 ， 这 也 是 它 和 action 不 同 的 地 方 ， 如 下 
两 种 特殊 的 写法 ， 它 们 的 作用 是 一 样 的 : 


<intent-filter . . .> 


<data android:scheme="file" android:host="www.baidu.com" 


</intent-filter> 
<intent-filter . . .> 
<data android:scheme="file" /> 


<data android:host="www.baidu.com" /> 


</intent-filter> 


到 这 里 我 们 已 经 把 IntentFilter 的 过 滤 规 则 都 讲解 了 一 过 ， 还 记得 本 
市 前 面 给 出 的 一 个 intent-filter 的 示例 吗 ? 现在 我 们 给 出 完全 匹配 它 的 


Intent: 


Intent intent = new Intent("com.ryg.charpter_1.c"); 
intent.addCategory("com.ryg.category.c"); 
intent.setDataAndType(Uri.parse("file://abc"), "text/plain" ); 


startActivity(intent); 


还 记得 URI 的 schema 是 有 默认 值 的 吗 ? 如 果 把 上 面 的 
intent.setDataAndType (Uri.parse("file://abc"),"text/plain") 这 人 句 改 成 
intent.setDataAndType(Uri.parse("http://abc"),"text/plain")， 打 开 Activity 的 
时 候 就 会 报错 ， 提 示 无 法 找到 Activity， 如 图 1-10 所 示 。 男 外 一 点 ， 
Intent-filter 的 匹配 规则 对 于 Service 和 BroadcastReceiver 也 是 同样 的 道理 ， 


不 过 系统 对 于 Service 的 建议 是 尽量 使 用 显 式 调用 方式 来 局 动 服务 。 





evel Application 
D com.ryg.chapter_1 








图 1-10 AAAS 





最 后 ， 当 我 们 通过 隐 式 方式 启动 一 个 Activity 的 时 候 ， 可 以 做 一 下 
判断 ， 看 是 否 有 Activity 能 够 岂 配 我 们 的 隐 式 Intent， 如 果 不 做 判断 就 有 
可 能 出 现 上 述 的 错误 了 。 判 断 方法 有 两 种 : 采用 PackageManager 的 
resolveActivity 方 法 或 者 Intent 的 resolveActivity 方 法 ， 如 果 它 们 找 不 到 匹 
配 的 Activity 就 会 返回 null， 我 们 通过 判断 返回 值 就 可 以 规避 上 述 错误 
了 了。 另外 ，PackageManager 还 提供 了 queryIntentActivities 方 法 ， 这 个 方 
法 和 resolveActivity 方 法 不 同 的 是 : 它 不 是 返回 最 佳 匹配 的 Activity 信 息 
而 是 返回 所 有 成 功 匹 配 的 Activity 人 信息。 我们 看 一 下 queryIntentActivities 
和 resolveActivity 的 方法 原型 : 





public abstract List<ResolveInfo> queryIntentActivities(Inten 
flags); 


public abstract ResolveInfo resolveActivity(Intent intent, int 


上 述 两 个 方法 的 第 一 个 参数 比较 好 理解 ， 第 二 个 参数 需要 注意 ， 我 
们 要 使 用 MATCH_DEFAULT_ONLY 这 个 标记 位 ， 这 个 标记 位 的 含义 是 
仅仅 匹配 那些 在 intent-filter 中 声明 了 <category 
android:name="android.intent.category.DEFAULT"/> 这 个 category 的 
Activity。 使 用 这 个 标记 位 的 意义 在 于 ， 只 要 上 述 两 个 方法 不 返回 null， 


那么 startActivity 一 定 可 以 成 功 。 如 果 不 用 这 个 标记 位 ， 就 可 以 把 intent- 
filter 中 category 不 含 DEFAULT 的 那些 Activity 给 匹配 出 来 ， 从 而 导致 
startActivity 可 能 失败 。 因 为 不 含有 DEFAULT 这 个 category 的 Activity 是 
无 法 接收 隐 式 Intent 的 。 在 action 和 category 中 ， 有 一 类 action 和 category 比 
较 重 要 ， 它 们 是 : 


<action android:name="android.intent.action.MAIN" /> 


<category android:name="android.intent.category.LAUNCHER" /> 


这 二 者 共同 作用 是 用 来 标明 这 是 一 个 入 口 Activity 并 且 会 出 现在 系 
统 的 应 用 列表 中 ， 少 了 任何 一 个 都 没有 实际 意义 ， 也 无 法 出 现在 系统 的 
应 用 列表 中 ， 也 就 是 二 者 缺 一 人 不可。 另外， 针对 Service 和 
BroadcastReceiver，PackageManager 同 样 提 供 了 类 似 的 方法 去 获取 成 功 
匹配 的 组 件 信 息 。 





第 2 章 ”1PC 机 制 


本 章 主 要 讲解 Android 中 的 IPC 机 制 。 首 先 介绍 Android 中 的 多 进程 
概念 以 及 多 进程 开发 模式 中 常见 的 注意 事项 ， 接 着 介绍 Android 中 的 序 
列 化 机 制 和 Binder， 然 后 详细 介绍 Bundle、 文 件 共享 、AIDL、 
Messenger、ContentProvider 和 Socket 等 进程 间 通 信 的 方式 。 为 了 更 好 地 
使 用 AIDL 来 进行 进程 间 通 信 ， 本 章 还 引入 了 Binder 连 接 池 的 概念 。 最 
后 ， 本 章 讲解 各 种 进程 间 通 信 方 式 的 优 缺 点 和 适用 场景 。 通 过 本 章 ， 可 
以 让 读者 对 Android 中 的 IPC 机 制 和 多 进程 开发 模式 有 深入 的 理解 。 





2.1 Android IPC 人 简介 


IPC 是 Inter-Process ”Communication 的 缩写 ， 含 义 为 进程 间 通 信 或 者 
跨 进 程 通信 ， 是 指 两 个 进程 之 间 进 行 数 据 交 换 的 过 程 。 说 起 进程 间 通 
信 ， 我 们 首先 要 理解 什么 是 进程 ， 什 么 是 线程 ， 进 程 和 线程 是 截然 不 同 
的 概念 。 按 照 操 作 系统 中 的 描述 ， 线 程 是 CPU 调度 的 最 小 单元 ， 同 时 线 
星 是 一 种 有 限 的 系统 资源 。 而 进程 一 般 指 一 个 执行 单元 ， 在 PC 和 移动 
设备 上 指 一 个 程序 或 者 一 个 应 用 。 一 个 进程 可 以 包含 多 个 线程 ， 因 此 进 
程 和 线程 是 包含 与 被 包含 的 关系 。 最 简单 的 情况 下 ， 一 个 进程 中 可 以 只 
有 一 个 线程 ， 即 主线 程 ， 在 Android 里 面 主线 程 也 叫 UI 线 程 ， 在 UI 线程 
里 才能 操作 界面 元 素 。 很 多 时 候 ， 一 个 进程 中 需要 执行 大 量 耗 时 的 任 
务 ， 如 果 这 些 任 务 放 在 主线 程 中 去 执行 就 会 造成 界面 无 法 啊 应 ， 严 重 影 
啊 用 户 体验 ， 这 种 情况 在 PC 系统 和 移动 系统 中 都 存在 ， 在 Android 中 有 
一 个 特殊 的 名 字 叫 做 ANR (Application Not Responding〉， 即 应 用 无 啊 
应 。 解 决 这 个 问题 束 需 要 用 到 线程 ， 把 一 些 耗 时 的 任务 放 在 线程 中 即 
可 。 

















IPC 不 是 Android 中 所 独 有 的 ， 任 何 一 个 操作 系统 都 需要 有 相应 的 
IPC 机 制 ， 比 如 Windows 上 可 以 通过 剪贴 板 、 管 道 和 邮 槽 等 来 进行 进程 
间 通 信 ，Linux 上 可 以 通过 命名 管道 、 共 享 内 容 、 信 号 量 等 来 进行 进程 
间 通 信 。 可 以 看 到 不 同 的 操作 系统 平台 有 痢 不 同 的 进程 间 通 信 方 式 ， 对 
于 Android 来 说 ， 它 是 一 种 基于 Linux 内 核 的 移动 操作 系统 ， 它 的 进程 间 
通信 方式 并 不 能 完全 继承 自 Linux， 相 反 ， 它 有 上 自己 的 进程 间 通 信 方 
式 。 在 Android 中 最 有 特色 的 进程 间 通 信 方 式 就 是 Binder 了 ， 通 过 Binder 
可 以 轻松 地 实现 进程 间 通 信 。 除 了 Binder，Android 还 支持 Socket， 通 过 








Socket 也 可 以 实现 任意 两 个 终端 之 间 的 通信 ， 当 然 同 一 个 设备 上 的 两 个 
进程 通过 Socket 通 信 自 然 也 是 可 以 的 。 


说 到 IPC 的 使 用 场景 束 必 须 提 到 多 进程 ， 只 有 和 面 对 多 进程 这 种 场景 
下 ， 才 需要 考虑 进程 间 通 信 。 这 个 是 很 好 理解 的 ， 如 果 只 有 一 个 进程 在 
运行 ， 又 何 谈 多 进程 呢 ? 多 进程 的 情况 分 为 两 种 。 第 一 种 情况 是 一 个 应 
用 因为 某 些 原因 目 身 需要 采用 多 进程 模式 来 实现 ， 至 于 原因 ， 可 能 有 很 
多 ， 比 如 有 些 模块 由 于 特殊 原因 需要 运行 在 单独 的 进程 中 ， 又 或 者 为 了 
加 大 一 个 应 用 可 使 用 的 内 存 所 以 需要 通过 多 进程 来 获取 多 份 内 存 空 间 。 
Android 对 单个 应 用 所 使 用 的 最 大 内 存 做 了 限制 ， 早 期 的 一 些 版 本 可 能 
是 16MB， 不 同 设备 有 不 同 的 大 小 。 男 一 种 情况 是 当前 应 用 需要 向 其 他 
应 用 获取 数据 ， 由 于 是 两 个 应 用 ， 所 以 必须 采用 跨 进 程 的 方式 来 获取 所 
需 的 数据 ， 甚 至 我 们 通过 系统 提供 的 ContentProvider 去 查询 数据 的 时 
候 ， 其 实 也 是 一 种 进程 间 通 信 ， 只 不 过 通信 细 贡 被 系统 内 部 屏 藤 了， 我 
们 无 法 感知 而 已 。 后 续 章 节 会 详细 介绍 ContentProvider 的 底层 实现 ， 这 
里 就 先 不 做 详细 介绍 了 。 总 之 ， 不 管 由 于 何 种 原因 ， 我 们 采用 了 多 进程 
的 设计 方法 ， 那 么 应 用 中 束 必 须 受 善 地 处 理 进 程 间 通信 的 各 种 问题 。 
































2.2 Android 中 的 多 进程 模式 


在 正式 介绍 进程 间 通 信之 前 ， 我 们 必须 先 要 理解 Android 中 的 多 进 
程 模式 。 通 过 给 四 大 组 件 指定 android:process 属 性 ， 我 们 可 以 轻易 地 开 
启 多 进程 模式 ， 这 看 起 来 很 简单 ， 但 是 实际 使 用 过 程 中 却 暗藏 杀机 ， 多 
进程 远 远 没有 我 们 想 的 那么 简单 ， 有 时 候 我 们 通过 多 进程 得 到 的 好 处 其 
至 都 不 足以 弥补 使 用 多 进程 所 带 来 的 代码 层面 的 负面 影响 。 下 面 会 详细 


分 析 这 些 问 题 。 


2.2.1 开局 多 进程 模式 


正常 情况 下 ， 在 Android 中 多 进程 是 指 一 个 应 用 中 存在 多 个 进程 的 
情况 ， 因 此 这 里 不 讨论 两 个 应 用 之 间 的 多 进程 情况 。 首 先 ， 在 Android 
中 使 用 多 进程 只 有 一 种 方法 ， 那 就 是 给 四 大 组 件 〈Activity、Service、 
Receiver, ContentProvider) 在 AndroidMenifest 中 指定 android:process 属 
性 ， 除 此 之 外 没有 其 他 办 法 ， 也 就 是 说 我 们 无 法 给 一 个 线程 或 者 一 个 实 
体 类 指定 其 运行 时 所 在 的 进程 。 其 实 还 有 另 一 种 非常 规 的 多 进程 方法 ， 
那 就 是 通过 JNI 在 native 层 去 fork 一 个 新 的 进程 ， 但 是 这 种 方法 属于 特殊 
情况 ， 也 不 是 常用 的 创建 多 进程 的 方式 ， 因 此 我 们 暂时 不 考虑 这 种 方 
式 。 下 面 是 一 个 示例 ， 描 述 了 如 何在 Android 中 创建 多 进程 : 











<activity 
android:name="com.ryg.chapter_2.MainActivity" 
android: configChanges="orientation|screenSize" 


android: label="@string/app_name" 


android: LaunchMode="standard" > 
<intent-filter> 
<action android:name="android.intent.action.MAIN" 
<category android:name="android.intent.category.L. 
</intent-filter> 
</activity 
<activity 
android: name="com.ryg.chapter_2.SecondActivity" 
android: configChanges="screenLayout" 
android: label="@string/app_name" 
android: process=":remote" /> 
<activity 
android: name="com.ryg.chapter_2.ThirdActivity" 
android: configChanges="screenLayout" 
android: label="@string/app_name" 


android: process="com.ryg.chapter_2.remote" /> 


上 面 的 示例 分 别 为 SecondActivity 和 ThirdActivity 指 定 了 process 属 

性 ， 并 且 它 们 的 属性 值 不 同 ， 这 意味 着 当前 应 用 叉 增 加 了 两 个 新 进程 。 
假设 当前 应 用 的 包 名 为 “com.ryg.chapter_2”， 当 SecondActivity 启 动 时 ， 
系统 会 为 它 创 建 一 个 单独 的 进程 ， 进 程 名 为 “com.ryg.chapter_2: 
remote”; 当 ThirdActivity 启 动 时 ， 系 统 也 会 为 它 创建 一 个 单独 的 进程 ， 
进程 名 为 “com.ryg.chapter_2.remote”。 同 时 入 口 Activity 是 MainActivity， 
没有 为 它 指定 process 属 性 ， 那 么 它 运 行 在 默认 进程 中 ， 默 认 进 程 的 进程 
名 是 包 名 。 下 面 我 们 运行 一 下 看 看 效果 ， 如 图 2-1 所 示 。 进 程 列表 末尾 
存在 3 个 进程 ， 进 程 id 分 别 为 645、659、672， 这 说 明 我 们 的 应 用 成 功 地 
使 用 了 多 进程 技术 ， 是 不 是 很 简单 呢 ? 这 只 是 开始 ， 实 际 使 用 中 多 进程 

















是 有 很 多 问题 需要 处 理 的 。 


avd4.0.3 [emulator-5554] 
system_process 
com.android.systemui 
com.android.inputmethod.|latin 


com.android.phone 


com.android.launcher 
com.android.settings 
android.process.acore 
com.android.calendar 
com.android.deskclock 
com.android.providers.calendar 
com.android.defcontainer 
android.process.media 
com.android.exchange 
com.android.email 
com.android.mms 
com.svox.pico 
com.estrongs.android.pop 
com.android.quicksearchbox 
com.android.keychain 
com.ryg.chapter_2 
com.ryg.chapter_2:remote 





com.ryg.chapter_2.remote 


图 2-1 系统 进程 列表 





除了 在 Eclipse 的 DDMS 视 图 中 得 看 进程 信息 ， 还 可 以 用 shell 来 得 
A, MON: adb shell ps 或 者 adb shell ps | grep com.ryg.chapter 2。 其 中 
SNe 2 是 包 名 ， 如 图 2-2 所 示 ， 通 过 ps 命令 也 可 以 查看 一 个 包 

名 中 当前 所 存在 的 进程 信息 。 

















不 知道 读者 朋友 有 没有 注意 到 ，SecondActivity 和 ThirdActivity 的 
android:process 属 性 分 别 为 “:remote” 和 “com.ryg.chapter_2.remote”， 那 么 
这 两 种 方式 有 区 别 吗 ? 其 实 是 有 区 别 的 ， 区 别 有 两 方面 : 首先 ,，“:” 的 含 
义 是 指 要 在 当前 的 进程 名 前 面 附加 上 当前 的 包 名 ， 这 是 一 种 简写 的 方 
法 ， 对 于 SecondActivity 来 说 ， 它 完整 的 进程 名 为 
com.ryg.chapter_2:remote， 这 一 点 通过 图 2-1 和 2-2 中 的 进程 信息 也 能 
出 来 ， 而 对 于 ThirdActivity 中 的 声明 方式 ， 它 是 一 种 完整 的 命名 方式 ， 

不 会 附加 包 名 信息 ; 其 次 ， 进 程 名 以 “:” 开 头 的 进程 属于 当前 应 用 的 私有 
进程 ， 其 他 应 用 的 组 件 不 可 以 和 它 跑 在 同一 个 进程 中 ， 而 进程 名 不 

以 “:” 开 头 的 进程 属于 全 局 进程 ， 其 他 应 用 通过 ShareUID 方 式 可 以 和 它 
跑 在 同一 个 进程 中 。 











我 们 知道 Android 系 统 会 为 每 个 应 用 分 配 一 个 唯一 的 UID， 具 有 相同 
UID 的 应 用 才能 共享 数据 。 这 里 要 说 明 的 是 ， 两 个 应 用 通过 ShareUID 跑 
在 同一 个 进程 中 是 有 要 求 的 ， 需 要 这 两 个 应 用 有 相同 的 ShareUID 并 且 签 
名 相同 才 可 以 。 在 这 种 情况 下 ， 它 们 可 以 互相 访问 对 方 的 私有 数据 ， 比 
如 data 目 录 、 组 件 信息 等 ， 不 管 它们 是 否 跑 在 同一 个 进程 中 。 当 然 如 果 
它们 跑 在 同一 个 进程 中 ， 那 么 除了 能 共享 data 目 录 、 组 件 信息 ， 还 可 以 
共享 内 存 数据 ， 或 者 说 它们 看 起 来 就 像 是 一 个 应 用 的 两 个 部 分 。 


2.2.2 ”多 进程 模式 的 运行 机 制 
如 果 用 一 句 话 来 形容 多 进程 ， 那 笔者 只 能 这 样 说 :“ 当 应 用 开启 了 


多 进程 以 后 ， 各 种 奇怪 的 现象 都 出 现 了 ”。 为 什么 这 么 说 呢 ? 这 是 有 原 
因 的 。 大 部 分 人 部 认为 开局 多 进程 是 很 简单 的 事情 ， 只 需要 给 四 大 组 件 











指定 android:process 属 性 即 可 。 比 如 说 在 实际 的 产品 开发 中 ， 可 能 会 有 
多 进程 的 需求 ， 需 要 把 某 些 组 件 放 在 单独 的 进程 中 去 运行 ， 很 多 人 都 会 
觉得 这 不 很 简单 吗 ? 然后 迅速 地 给 那些 组 件 指定 了 android:process 属 

性 ， 然 后 编译 运行 ， 发 现 “ 正 常 地 运行 起 来 了 ”。 这 里 笔者 想 说 的 是 ， 那 
是 真 的 正常 地 运行 起 来 了 吗 ? 现在 先 不 置 可 否 ， 下 面 先 给 举 个 例子 ， 然 
后 引入 本 节 的 话题 。 还 是 本 章 刚 开始 说 的 那个 例子 ， 其 中 
SecondActivity 通 过 指定 android:process 属 性 从 而 使 其 运行 在 一 个 独立 的 
进程 中 ， 这 里 做 了 一 些 改动 ， 我 们 新 建 了 一 个 类 ， 叫 做 UserManager， 
这 个 类 中 有 一 个 public 的 静态 成 员 变 量 ， 如 下 上 所 示 。 








public class UserManager { 
public static int sUserId = 1; 


} 


然后 在 MainActivity 的 onCreate 中 我 们 把 这 个 sSUserId 重 新 赋值 为 2， 
打印 出 这 个 静态 变量 的 值 后 再 启动 SecondActivity， 在 SecondActivity 中 
我 们 再 打印 一 下 sUserId 的 值 。 按 照 正常 的 逻辑 ， 静 态 变 量 是 可 以 在 所 有 
的 地 方 共 享 的 ， 并 且 一 处 有 修改 处 处 都 会 同步 ， 图 2-3 是 运行 时 所 打印 
的 日 志 ， 我 们 看 一 下 结果 如 何 。 








Level PID TID Application Tag Text 
686 686 com.ryg.chapter_2 MainActivity UserManage. sUserId=2 
722 722 com.ryg.chapter_2:remote SecondActivity onCreate 


com.ryg.chapter_2:remote SecondActivity UserManage.sUserId=1 








图 2-3 系统 日 志 


看 了 图 2-3 中 的 日 志 ， 发 现 结果 和 我 们 想 的 完全 不 一 致 ， 正 常情 况 
下 SecondActivity 中 打印 的 sUserId 的 值 应 该 是 2 才 对 ， 但 是 从 日 志 上 看 它 
竟然 还 是 1， 可 是 我 们 的 确 已 经 在 MainActivity 中 把 sUserId 重 新 赋值 为 2 














了 。 看 到 这 里 ， 大 家 应 该 明白 了 这 就 是 多 进程 所 带 来 的 问题 ， 多 进程 绝 
非 只 是 仅仅 指定 一 个 android:process 属 性 那么 简单 。 


上 述 问题 出 现 的 原因 是 SecondActivity 运 行 在 一 个 单独 的 进程 中 ， 
我 们 知道 Android 为 每 一 个 应 用 分 配 了 一 个 独立 的 虚拟 机 ， 或 者 说 为 每 
个 进程 都 分 配 一 个 独立 的 虚拟 机 ， 不 同 的 虚拟 机 在 内 存 分 配 上 有 不 同 的 
地 址 空间 ， 这 融 导 致 在 不 同 的 虚拟 机 中 访问 同一 个 类 的 对 象 会 产生 多 份 
副本 。 拿 我 们 这 个 例子 来 说 ， 在 进程 com.ryg.chapter_ 2 和 进程 
com.ryg.chapter_2:remote 中 都 存在 一 个 UserManager 类 ， 并 且 这 两 个 类 是 
互 不 干扰 的 ， 在 一 个 进程 中 修改 sUserId 的 值 只 会 影响 当前 进程 ， 对 其 他 
进程 不 会 造成 任何 影响 ， 这 样 我 们 就 可 以 理解 为 什么 在 MainActivity 中 
修改 了 sUserId 的 值 ， 但 是 在 SecondActivity 中 sUserId 的 值 却 没 有 发 生 改 
变 这 个 现象 。 











所 有 运行 在 不 同 进程 中 的 四 大 组 件 ， 只 要 它们 之 间 需 要 通过 内 存 来 
共有 至 数据 ， 都 会 共享 失败 ， 这 也 是 多 进程 所 布 来 的 主要 有 影响。 正常 情况 
下 ， 四 大 组 件 中 间 不 可 能 不 通过 一 些 中 间 层 来 共 至 数据 ， 那 么 通过 简单 
地 指定 进程 名 来 开局 多 进程 都 会 无 法 正确 运行 。 当 然 ， 特 殊 情 况 下 ， 茶 
些 组 件 之 间 不 需要 共 孚 数据 ， 这 个 时 候 可 以 直接 指定 android:process 属 
性 来 开局 多 进程 ， 但 是 这 种 场景 是 不 利 见 的 ， 几 乎 所 有 情况 都 需要 共 孚 
数据 。 
































一 般 来 说 ， 使 用 多 进程 会 造成 如 下 几 方 面 的 问题 : 


WY 


(1) 静态 成 员 和 单 例 模 式 完 全 失效 。 


WY 


(2) 线程 同步 机 制 完 全 失效 。 


WY 


(3) SharedPreferences 的 可 靠 性 下 降 。 


(4) Applications: 4 1K Gi) 





第 1 个 问题 在 上 面 已 经 进行 了 分 析 。 第 2 个 问题 本 质 上 和 第 一 个 问题 

是 类 似 的 ， 既 然 都 不 是 一 块 内 存 了 ， 那 么 不 管 是 锁 对 象 还 是 锁 全 局 类 都 
无 法 保证 线程 同步 ， 因 为 不 同 进程 锁 的 不 是 同一 个 对 象 。 第 3 个 问题 是 
Ae piece Sc PAT Meee PIR A AT RE: 否则 会 导致 
一 定 几 率 的 数据 丢失 ， 这 是 因为 SharedPreferences 底 层 是 通过 读 / 写 XML 
文件 来 实现 的 ， 并 发 写 显然 是 可 能 出 问题 的 ， 甚 至 并 发 读 / 写 都 有 可 能 
出 问题 。 第 4 个 问题 也 是 显而易见 的 ， 当 一 个 组 件 跑 在 一 个 新 的 进程 中 
的 时 候 ， 由 于 系统 要 在 创建 新 的 进程 同时 分 配 独立 的 虚拟 机 ， 所 以 这 个 
过 程 其 实 就 是 局 动 一 个 应 用 的 过 程 。 因 此 ， 相 当 于 系统 又 把 这 个 应 用 重 
新 启动 了 一 这， 既然 重新 启动 了 ， 那 么 自然 会 创建 新 的 Application。 这 

个 问题 其 实 可 以 这 么 理解 ， 运 行 在 同一 个 进程 中 的 组 件 是 属于 同一 个 虚 
拟 机 和 同一 个 Application 的 ， 同 理 ， 运 行 在 不 同 进程 中 的 组 件 是 属于 两 
个 不 同 的 虚拟 机 和 Application 的 。 为 了 更 加 清晰 地 展示 这 一 点 ， 下 面 我 
们 来 做 一 个 测试 ， 首 先 在 Application 的 onCreate 方 法 中 打印 出 当前 进程 
的 名 字 ， 然 后 连续 启动 三 个 同一 个 应 用 内 但 属于 不 同 进 程 的 Activity， 
按照 期 望 ，Application 的 onCreate 应 该 执行 三 次 并 打印 出 三 次 进程 名 不 
同 的 log， 代 码 如 下 所 示 。 











public class MyApplication extends Application { 
private static final String TAG = "MyApplication"; 
@Override 
public void onCreate() { 
super.onCreate(); 
String processName = MyUtils.getProcessName(getAppli 


Process.myPid()); 


Log.d(TAG, "application start,process name:" + proces 


运行 后 看 一 下 log， 如 图 2-4 所 示 。 通 过 log 可 以 看 出 ，Application 执 
行 了 三 次 onCreate， 并 且 每 次 的 进程 名 称 和 进程 id 都 不 一 样 ， 它 们 的 进 
程 名 和 我 们 为 Activity 指 定 的 android:process 属 性 一 致 。 这 也 就 证 实 了 在 
多 进程 模式 中 ， 不 同 进程 的 组 件 的 确 会 拥有 独立 的 虚拟 机 、Application 
以 及 内 存 空间 ， 这 会 给 实际 的 开发 带 来 很 多 困扰 ， 是 尤其 需要 注意 的 。 
或 者 我 们 也 可 以 这 么 理解 同一 个 应 用 间 的 多 进程 ， 它 就 相当 于 两 个 不 同 
的 应 用 采用 了 SharedUID 的 模式 ， 这 样 能 够 更 加 直接 地 理解 多 进程 模式 
的 本 质 。 








Level PID Tag Text 

D 28299 MyApplication application start, process name:com.ryg.chapter_ 2 
28356 MyApplication application start, process name:com.ryg.chapter_2:remote 
28385 MyApplication application start, process name:com.ryg.chapter_2.remote 





图 2-4 系统 日 志 


本 节 我 们 分 析 了 多 进程 所 带 来 的 问题 ， 但 是 我 们 不 能 因为 多 进程 有 
很 多 问题 就 不 去 正视 它 。 为 了 解决 这 个 问题 ， 系 统 提 供 了 很 多 路 进程 通 
信和 方法， 虽然 说 不 能 直接 地 共 且 内存， 但 是 通过 中 进程 通信 我 们 还 是 可 
以 实现 数据 交互 。 实 现 路 进程 通信 的 方式 很 多 ， 比 如 通过 Intent 来 传递 
数据 ， 共 享 文件 和 SharedPreferences， 基 于 Binder 的 Messenger 和 AIDL 以 
及 Socket 等 ， 但 是 为 了 更 好 地 理解 各 种 IPC 方 式 ， 我 们 需要 先 熟 悉 一 些 
基础 概念 ， 比 如 序列 化 相关 的 Serializable 和 Parcelable 接 口 ， 以 及 Binder 
的 概念 ， 熟 悉 完 这 些 基础 概念 以 后 ， 再 去 理解 各 种 IPC 方 式 就 比较 简单 
Jg 


2.3 IJPC 基 础 概念 介绍 


本 节 主 要 介绍 IPC 中 的 一 些 基 础 概念 ， 主 要 包含 三 方面 内 容 : 
Serializable 接 口 、Parcelable 接 口 以 及 Binder， 只 有 熟悉 这 三 方面 的 内 容 
后 ， 我 们 才能 更 好 地 理解 路 进程 通信 的 各 种 方式 。 ee 
Parcelable 接 口 可 以 完成 对 象 的 序列 化 过 程 ， 当 我 们 需要 通过 Intent 和 
Binder 传 输 数 据 时 就 需要 使 用 Parcelable 或 者 Serializable。 nee 的 时 候 我 
们 需要 把 对 象 持久 化 到 存储 设备 上 或 者 通过 网 络 传输 给 其 他 客户 端 ， 这 
个 时 候 也 需要 使 用 Serializable 来 完成 对 象 的 持久 化 ， 下 面 先 介绍 如 何 使 
用 Serializable 来 完成 对 象 的 序列 化 。 











2.3.1 ”Serializable 接 口 


Serializable 是 Java 所 提供 的 一 个 序列 化 接口 ， 它 是 一 个 空 接 口 ， 为 
对 象 提 供 标准 的 序列 化 和 反 序 列 化 操作 。 使 用 Serializable 来 实现 序列 化 
相当 简单 ， 只 需要 在 类 的 声明 中 指定 一 个 类 似 下 面 的 标识 即 可 自动 实现 
默认 的 序列 化 过 程 。 








private static final long serialVersionUID = 8711368828010083 


在 Android 中 也 提供 了 新 的 序列 化 方式 ， 那 就 是 Parcelable 接 口 ， 使 
用 Parcelable 来 实现 对 象 的 序列 号 ， 其 过 程 要 稍微 复杂 一 些 ， a z 
Serializable 接 口 。 上 面 提 到 ， 想 让 一 个 对 象 实现 序列 化 ， 只 需要 这 个 类 
实现 Serializable 接 口 并 声明 一 个 serialVersionUID 即 可 ， 实 际 上 ， 甚 至 这 
个 serialVersionUID 也 不 是 必需 的 ， 我 们 不 声明 这 个 serialVersionUID 同 





样 也 可 以 实现 序列 化 ， 但 是 这 将 会 对 反 序 列 化 过 程 产生 影响 ， 具 体 什 么 
影响 后 面 再 介绍 。User 类 束 是 一 个 实现 了 Serializable 接 口 的 类 ， 它 是 可 
以 被 序列 化 和 反 序 列 化 的 ， 如 下 所 示 。 


public class User implements Serializable { 
private static final long serialVersionUID = 51906712372 
public int userId; 
public String userName; 


public boolean isMale; 











通过 Serializable 方 式 来 实现 对 象 的 序列 化 ， 实 现 起 来 非常 简单 ， 几 
乎 所 有 工作 都 被 系统 目 动 完 成 了 。 如 何 进行 对 象 的 序列 化 和 反 序 列 化 也 
非常 简单 ， 只 需要 采用 ObjectOutputStream 和 ObjectInputStream 即 可 轻松 
实现 。 下 面 举 个 简单 的 例子 。 


// 序 列 化 过 程 

User user = new User(0, "jake", true); 

ObjectOutputStream out = new ObjectOutputStream( 
new FileOutputStream("cache.txt")); 

out.writeObject(user); 

out.close(); 

// 反 序列 化 过 程 

ObjectInputStream in = new ObjectInputStream( 
new FileInputStream("cache.txt")); 

User newUser = (User) in.readObject(); 


in.close(); 


上 述 代码 演示 了 采用 Serializable 方 式 序 列 化 对 象 的 典型 过 程 ， 很 简 
单 ， 只 需要 把 实现 了 Serializable 接 口 的 User 对 象 写 到 文件 中 就 可 以 快速 
恢复 了 ， 人 恢复 后 的 对 象 newUser 和 user 的 内 容 完全 一 样 ， 但 是 两 者 并 不 
是 同一 个 对 象 。 


刚 开 始 提 到 ， 即 使 不 指定 serialVersionUID 也 可 以 实现 序列 化 ， 那 到 
底 要 不 要 指定 昵 ? 如 果 指 定 的 话 ，serialVersionUID 后 面 那 一 长 串 数 字义 
是 什么 含义 呢 ? 我 们 要 明白 ， 系 统 既 然 提供 了 这 个 serialVersionUID， 那 
么 它 必 须 是 有 用 的 。 这 个 serialVersionUID 是 用 来 辅助 序列 化 和 反 序 列 化 
过 程 的 ， 原 则 上 序列 化 后 的 数据 中 的 serialVersionUID 只 有 和 当前 类 的 
serialVersionUID 相 同 才能 够 正常 地 被 反 序 列 化 。serialVersionUID 的 详 
细 工 作 机 制 是 这 样 的 : 序列 化 的 时 候 系统 会 把 当前 类 的 serialVersionUID 
写 入 序列 化 的 文件 中 《也 可 能 是 其 他 中 介 ) ， 当 反 序 列 化 的 时 候 系统 会 
去 检测 文件 中 的 serialVersionUID， 看 它 是 否 和 当前 类 的 
serialVersionUID 一 致 ， 如 果 一 致 束 说明 序 列 化 的 类 的 版 本 和 当前 类 的 版 
本 是 相同 的 ， 这 个 时 候 可 以 成 功 反 序 列 化 ; 否则 就 说 明 当 前 类 和 序列 化 
的 类 相 比 发 生 了 某 些 变换 ， 比 如 成 员 变 量 的 数量 、 类 型 可 能 发 生 了 改 
变 ， 这 个 时 候 是 无 法 正常 反 序 列 化 的 ， 因 此 会 报 如 下 错误 : 





java.io.InvalidClassException: Main; local class incompatible 
classdesc serialVersionUID = 8711368828010083044, local class 
VersionUID = 8711368828010083043. 





一 般 来 说 ， 我 们 应 该 手动 指定 serialVersionUID 的 值 ， 比 如 1L， 也 
可 以 让 Eclipse 根据 当前 类 的 结构 自动 去 生成 它 的 hash 值 ， 这 样 序列 化 和 
反 序 列 化 时 两 者 的 serialVersionUID 是 相同 的 ， 因 此 可 以 正常 进行 反 序列 
化 。 如 果 不 手动 指 定 serialVersionUID 的 值 ， 反 序列 化 时 当前 类 有 所 改 
变 ， 比 如 增加 或 者 删除 了 某 些 成 员 变 量 ， 那 么 系统 就 会 重新 计算 当前 类 








的 hash 值 并 把 它 赋值 给 serialVersionUID， 这 个 时 候 当 前 类 的 
serialVersionUID 就 和 序列 化 的 数据 中 的 serialVersionUID 不 一 致 ， 于 是 
反 序 列 化 失败 ， 程 序 就 会 出 现 crash。 所 以 ， 我 们 可 以 明显 感觉 到 
serialVersionUID 的 作用 ， 当 我 们 手动 指定 了 和 它 以 后 ， 束 可 以 在 很 大 程度 
上 避免 肥 序列 化 过 程 的 失败 。 比 如 当 版 本 升级 后 ， 我 们 可 能 删除 了 某 个 
成 员 变 量 也 可 能 增加 了 一 些 新 的 成 员 变 量 ， 这 个 时 候 我 们 的 反 同 序列 化 
过 程 仍然 能 够 成 功 ， 程 序 仍然 能 够 最 大 限度 地 恢复 数据 ， 相 反 ， 如 有 果 不 
虽 定 serialVersionUID 的 话 ， 程 序 则 会 挂 掉 。 当 然 我 们 还 要 考虑 另外 一 种 
情况 ， 如 果 类 结构 发 生 了 非常 规 性 改变 ， 比 如 修改 了 类 名 ， 修 改 了 成 员 
变量 的 类 型 ， 这 个 时 候 尽管 serialVersionUID 验 证 通过 了 ， 但 是 反 序 列 化 
过 程 还 是 会 失败 ， 因 为 类 结构 有 了 毁灭 性 的 改变 ， 根 本 无 法 从 老 版 本 的 
数据 中 还 原 出 一 个 新 的 类 结构 的 对 象 。 

















根据 上 面 的 分 析 ， 我 们 可 以 知道 ， 给 serialVersionUID 指 定 为 1L 或 
者 采用 Eclipse 根据 当前 类 结构 去 生成 的 hash 值 ， 这 两 者 并 没有 本 质 区 
别 ， 效 果 完 全 一 样 。 以 下 两 点 需要 特别 提 一 下 ， 首 先 静 态 成 员 变 量 属于 
类 不 属于 对 象 ， 所 以 不 会 参与 序列 化 过 程 ， 其 次 用 transient 关 键 字 标记 
的 成 员 变 量 不 参与 序列 化 过 程 。 











男 外 ， 系 统 的 默认 厅 列 化 过 程 也 是 可 以 改变 的 ， 通 过 
方法 即 可 重 写 系统 默认 的 序列 化 和 反 序 列 化 过 程 ， 有 共 体 怎 
个 方法 就 是 很 简单 的 事 了 ， 这 里 就 不 再 详细 介绍 了 ， 毕 竟 
重点 ， 而 且 大 部 分 情况 下 我 们 不 需要 重 写 这 两 个 方法 。 


实现 如 下 两 个 
么 去 重 写 这 两 
这 不 是 本 章 的 











private void writeObject(java.io.ObjectOutputStream out) 
throws IOException { 


// write 'this' to ‘out'... 


private void readObject(java.io.ObjectInputStream in) 
throws IOException,ClassNotFoundException { 


// populate the fields of 'this' from the data in ‘in'... 


2.3.2 Parcelable# O 











上 一 节 我 们 介绍 了 通过 Serializable 方 式 来 实现 序列 化 的 方法 ， 本 节 
接着 介 人 
要 实现 这 个 接口 ， 一 个 类 的 对 象 就 可 以 实现 序列 化 并 可 以 通过 Intent 和 
Binder 传 递 。 下 面 的 示例 是 一 个 典型 的 用 法 。 





public class User implements Parcelable { 

public int userId; 

public String userName; 

public boolean isMale; 

public Book book; 

public User(int userId,String userName, boolean isMale) { 
this.userId = userId; 
this.userName = userName; 
this.isMale = isMale; 

} 

public int describeContents() { 
return 0; 


} 


public void writeToParcel(Parcel out,int flags) { 


这 里 先 说 一 下 Parcel，Parcel 内 部 包装 了 可 序列 化 的 数据 ， 可 以 在 
Binder 中 自由 传输 。 从 上 述 代码 中 可 以 看 出 ， 在 序列 化 过 程 中 需要 实现 
的 功能 有 序列 化 、 反 序列 化 和 内 容 描 述 。 序 列 化 功能 由 writeToParcel 方 
法 来 完成 ， 最 终 是 通过 Parcel 中 的 一 系列 write 方 法 来 完成 的 ， 反 序列 化 





功能 由 CREATOR 来 完成 ， 其 内 部 标明 了 如 何 创建 序列 化 对 象 和 数组 ， 
并 通过 Parcel 的 一 系列 read 方 法 来 完成 反 序列 化 过 程 ; 内 容 描述 功能 
describeContents 方 法 来 完成 ， 几 乎 在 所 有 情况 下 这 个 方法 都 应 该 返回 

0， 仅 当当 前 对 象 中 存在 文件 摘 述 符 时 ， 此 方法 返回 1。 需 要 注意 的 是 ， 
在 User(Parcel in) 方 法 中 ， 由 于 book 是 男 一 个 可 序列 化 对 象 ， 所 以 它 的 有 反 
序列 化 过 程 需要 传递 当前 线程 的 上 下 文 类 加 载 器 ， 否 则 会 报 无 法 找到 类 
的 错误 。 详 细 的 方法 说 明 请 参看 表 2-1。 








表 2-1 Parcelable 的 方法 说 明 


功 能 
从 序列 化 后 的 对 象 中 创建 原始 对 象 
创建 指定 长 度 的 原始 对 象 数组 
User(Parcel in) 从 序列 化 后 的 对 象 中 创建 原始 对 象 
将 当前 对 象 写 入 序列 化 结构 中 ， 其 中 flags 














writeToParcel 标识 有 两 种 值 : 0 或 者 1 (参见 右 侧 标记 位 )。 
(Parcel out, int flags) 为 1 时 标识 当前 对 象 需要 作为 返回 值 返回 ， 不 
能 立即 释放 资源 ， 几 乎 所 有 情况 都 为 0 


PARCELABLE WRITE RETURN VALUE 








返回 当前 对 象 的 内 容 描 述 。 如 果 含 有 文件 描 
述 符 ， 返回 1 (参见 右 侧 标记 位 )， 否 则 返回 0，| CONTENTS_FILE DESCRIPTOR 
几乎 所 有 情况 都 返回 0 











系统 已 经 为 我 们 提供 了 许多 实现 了 Parcelable 接 口 的 类 ， 它 们 都 是 可 
以 直接 序列 化 的 ， 比 如 Intent、Bundle、Bitmap 等 ， 同 时 List 和 Map 也 可 
以 序列 化 ， 前 提 是 它们 里 面 的 每 个 元 素 都 是 可 序列 化 的 。 





既然 Parcelable 和 Serializable 都 能 实现 序列 化 并 且 都 可 用 于 Intent 间 
的 数据 传递 ， 那 么 二 者 该 如 何 选取 呢 ? Serializable 是 Java 中 的 序列 化 接 
口 ， 其 使 用 起 来 简单 但 是 开销 很 大 ， 序 列 化 和 反 序 列 化 过 程 需要 大 量 
IO 操作 。 而 Parcelable 是 Android 中 的 序列 化 方式 ， 因 此 更 适合 用 在 
Android 平 台 上 ， 它 的 缺点 就 是 使 用 起 来 稍微 麻烦 点 ， 但 是 它 的 效率 很 
高 ， 这 是 Android 推 荐 的 序列 化 方式 ， 因 此 我 们 要 首选 Parcelable。 
Parcelable 主 要 用 在 内 存 序列 化 上 ， 通 过 Parcelable 将 对 象 序列 化 到 存储 





设备 中 或 者 将 对 象 序列 化 后 通过 网 络 传输 也 都 是 可 以 的 ， 但 是 这 个 过 程 
会 稍 显 复杂 ， 因 此 在 这 两 种 情况 下 建议 大 家 使 用 Serializable。 以 上 就 是 
Parcelable 和 Serializable 和 区 别 。 


2.3.3 Binder 


Binder 是 一 个 很 深入 的 话题 ， 笔 者 也 看 过 一 些 别人 写 的 Binder 相 关 
的 文章 ， 发 现 很 少 有 人 能 把 它 介绍 清楚 ， 不 是 深入 代码 细节 不 能 自拔 ， 
就 是 长 篇 大 论 不 知 所 云 ， 看 完 后 都 是 党 军 的 感觉 。 所 以 ， 本 节 笔 者 不 打 
算 深 入 探讨 Binder 的 底层 细节 ， 因 为 Binder 太 复杂 了 。 本 节 的 侧重 点 是 
介绍 Binder 的 使 用 以 及 上 层 原 理 ， 为 接 下 来 的 几 节 内 容 做 铺垫 。 








直观 来 说 ，Binder 是 Android 中 的 一 个 类 ， 它 继承 了 IBinder 接 口 。 从 
IPC 角 度 来 说 ，Binder 是 Android 中 的 一 种 路 进 程 通信 方式 ， 
以 理解 为 一 种 虚拟 的 物理 设备 ， 它 的 设备 驱动 是 /dev/binder， 访 通信 方 
式 在 Linux 中 没有 ; 从 Android Framework f§ EKR i, Binderz 
ServiceManager 连 接 各 种 Manager (ActivityManager. WindowManager;, 
等 等 ) 和 相应 ManagerService 的 桥 妆 ;从 Android 应 用 层 来 说 ，Binder 是 
客户 端 和 服务 端 进行 通信 的 媒介 ， 当 bindService 的 时 候 ， 服 务 端 会 返回 
一 个 包含 了 服务 端 业务 调用 的 Binder 对 象 ， EE ede 客户 
端 就 可 以 获取 服务 端 提 供 的 服务 或 者 数据 ， 这 里 的 服务 包括 普通 服务 和 
基于 AIDL 的 服务 。 


Android 开 发 中 ，Binder 主 要 用 在 Service 中 ， 包 括 AIDL 和 
Messenger， 其 中 普通 Service 中 的 Binder 不 涉及 进程 间 通 信 ， 所 以 较为 简 
单 ， 无 法 触及 Binder 的 核心 ， 而 Messenger 的 底层 其 实 是 AIDL， 所 以 这 
里 选择 用 AIDL 来 分 析 Binder 的 工作 机 制 。 为 了 分 析 Binder 的 工作 机 制 ， 


我 们 需要 新 建 一 个 AIDL 示 例 ，SDK 会 自动 为 我 们 生产 AIDL 所 对 应 的 
Binder 类 ， 然 后 我 们 就 可 以 分 析 Binder 的 工作 过 程 。 还 是 采用 本 章 开 始 
时 用 的 例子 ， 新 建 Java 包 com.ryg.chapter_2.aidl， 然 后 新 建 三 个 文件 
Book.java、Book.aidl 和 IBookManager.aidl， 人 代码 如 下 所 示 。 





//Book. java 

package com.ryg.chapter_2.aidl; 

import android.os.Parcel; 

import android.os.Parcelable; 

public class Book implements Parcelable { 
public int bookId; 
public String bookName; 
public Book(int bookId,String bookName) { 

this.bookId = bookId; 


this.bookName = bookName; 


public int describeContents() { 
return 0; 
} 
public void writeToParcel(Parcel out,int flags) { 
out.writeInt(bookId); 
out.writeString(bookName); 
J 
public static final Parcelable.Creator<Book> CREATOR = n 
Creator<Book>() { 
public Book createFromParcel(Parcel in) { 


return new Book(in); 





上 面 三 个 文件 中 ，Book.java 是 一 个 表示 图 书信 息 的 类 ， 它 实现 了 
Parcelable 接 口 。Book.aidl 是 Book 类 在 AIDL 中 的 声明 。 
IBookManager.aidl 是 我 们 定义 的 一 个 接口 ， 里 面 有 两 个 方法 : 
getBookList 和 addBook， 其 中 getBookList 用 于 从 远程 服务 端 获 取 图 书 列 
表 ， 而 addBook 用 于 往 图 书 列表 中 添加 一 本 书 ， 当 然 这 两 个 方法 主要 是 
示例 用 ， 不 一 定 要 有 实际 意义 。 我 们 可 以 看 到 ， 尽 管 Book 类 已 经 和 


IBookManager 位 于 相同 的 包 中 ， 但 是 在 IBookManager 中 仍然 要 导入 
Book 类 ， 这 就 是 AIDL 的 特殊 之 处 。 下 面 我 们 先 看 一 下 系统 为 
IBookManager.aid] 生 产 的 Binder 类 ， 在 gen 目 录 下 的 
com.ryg.chapter_2.aidl 包 中 有 一 个 IBookManager.java 的 类 ， 这 就 是 我 们 
要 找 的 类 。 接 下 来 我 们 需要 根据 这 个 系统 生成 的 Binder 类 来 分 析 Binder 
的 工作 原理 ， 代 码 如 下 : 





//TBookManager ,java 
/* 
* This file is auto-generated. DO NOT MODIFY. 
* Original file: E:\\workspace\\Chapter_2\\src\\com\\ryg\\c 
aid1l\\IBookManager .aidl 
ey 
package com.ryg.chapter_2.aidl; 
public interface IBookManager extends android.os.IInterface { 
/** Local-side IPC implementation stub class. */ 
public static abstract class Stub extends android.os.Bin 
com.ryg.chapter_2.aidl.IBookManager { 
private static final java.lang.String DESCRIPTOR = " 
2.aid1.IBookManager"; 
/** Construct the stub at attach it to the interface 
public Stub() { 
this.attachInterface(this, DESCRIPTOR) ; 
} 
/** 
* Cast an IBinder object into an com.ryg.chapter_2. 


* interface, generating a proxy if needed. 














A 


public java.util.List<com.ryg.chapter_2.aidl.Book> getBo 
throws android.os.RemoteException; 
public void addBook(com.ryg.chapter_2.aid1l.Book book) 


throws android.os.RemoteException; 


} 


上 述 代码 是 系统 生成 的 ， 为 了 方便 得 看 笔者 稍微 做 了 一 下 格式 上 的 
调整 。 在 gen 目 录 下 ， 可 以 看 到 根据 IBookManager.aidl 系 统 为 我 们 生成 
了 IBookManager.java 这 个 类 ， 它 继承 了 IInterface 这 个 接口 ， 同 时 它 自己 
也 还 是 个 接口 ， 所 有 可 以 在 Binder 中 传输 的 接口 都 需要 继承 IInterface 接 
口 。 这 个 类 刚 开 始 看 起 来 逻辑 混乱 ， 但 是 实际 上 还 是 很 清晰 的 ， 通 过 它 
我 们 可 以 清楚 地 了 解 到 Binder 的 工作 机 制 。 这 个 类 的 结构 其 实 很 简单 ， 
首先 ， 它 声明 了 两 个 方法 getBookList 和 addBook， 显 然 这 就 是 我 们 在 
IBookManager.aidl 中 所 声明 的 方法 ， 同 时 它 还 声明 了 两 个 整 型 的 id 分 别 
用 于 标识 这 两 个 方法 ， 这 两 个 id 用 于 标识 在 transact 过 程 中 客户 端 所 请 求 
的 到 底 是 哪个 方法 。 接 着 ， 它 声明 了 一 个 内 部 类 Stub， 这 个 Stub 就 是 一 
个 Binder 类 ， 当 客户 端 和 服务 端 都 位 于 同一 个 进程 时 ， 方 法 调用 不 会 走 
跨 进 程 的 transact 过 程 ， 而 当 两 者 位 于 不 同 进程 时 ， 方 法 调用 需要 走 
transact 过 程 ， 这 个 逻辑 由 Stub 的 内 部 代理 类 Proxy 来 完成 。 这 么 来 看 ， 
IBookManager 这 个 接口 的 确 很 简单 ， 但 是 我 们 也 应 该 认识 到 ， 这 个 接口 
的 核心 实现 就 是 它 的 内 部 类 Stub 和 Stub 的 内 部 代理 类 Proxy， 下 面 详 细 介 
绍 针对 这 两 个 类 的 每 个 方法 的 含义 。 








DESCRIPTOR 


Binder 的 唯一 标识 ， 一 般 用 当前 Binder 的 类 名 表示 ， 比 如 本 例 中 
的 “com.ryg.chapter_2.aidl.IBookManager”。 


asInterface(android.os.[ Binder obj) 


用 于 将 服务 端的 Binder 对 象 转换 成 客户 端 所 需 的 AIDL 接 口 类 型 的 对 
象 ， 这 种 转换 过 程 是 区 分 进程 的 ， 如 果 客 户 端 和 服务 端 位 于 同一 进程 ， 
那么 此 方法 返回 的 就 是 服务 端的 Stub 对 象 本 身 ， 否 则 返回 的 是 系统 封装 
后 的 Stub.proxy 对 象 。 





asBinder 
此 方法 用 于 返回 当前 Binder 对 象 。 
onTransact 


这 个 方法 运行 在 服务 端 中 的 Binder 线 程 池 中 ， 当 客户 端 发 起 跨 进 程 
请 求 时 ， 远 程 请 求 会 通过 系统 底层 封装 后 交 由 此 方法 来 处 理 。 该 方法 的 
原型 为 public Boolean onTransact(int code,android.os.Parcel 
data,android.os.Parcel reply,int flags)。 服 务 端 通过 code 可 以 确定 客户 端 所 
请 求 的 目标 方法 是 什么 ， 接 着 从 data 中 取出 目标 方法 所 需 的 参数 〈 如 果 
目标 方法 有 参数 的 话 ) ， 然 后 执行 目标 方法 。 当 目标 方法 执行 完毕 后 ， 
就 同 reply 中 写 入 返回 值 〈( 如 果 目 标 方法 有 返回 值 的 话 )，onTransact 方 
法 的 执行 过 程 就 是 这 样 的 。 需 要 注意 的 是 ， 如 果 此 方法 返回 false， 那 么 
客户 端的 请 求 会 失败 ， 因 此 我 们 可 以 利用 这 个 特性 来 做 权限 验证 ， 毕 竟 
我 们 也 不 希望 随便 一 个 进程 都 能 远程 调用 我 们 的 服务 。 


Proxy#getBookList 


这 个 方法 运行 在 客户 端 ， 当 客户 端 远程 调用 此 方法 时 ， 它 的 内 部 实 
现 是 这 样 的 ;首先 创建 该 方法 所 需要 的 输入 型 Parcel 对 象 _data、 输 出 型 
Parcel 对 象 _reply 和 返回 值 对 象 List; 然后 把 该 方法 的 参数 信息 写 入 _data 


中 (如 果 有 参数 的 话 ) ; 接着 调用 transact 方 法 来 发 起 RPC (远程 过 程 调 
用 ) 请 求 ， 同 时 当前 线程 挂 起 ;然后 服务 端的 onTransact 方 法 会 被 调 
用 ， 直 到 RPC 过 程 返回 后 ， 当 前 线程 继续 执行 ， 并 从 _reply 中 取出 RPC 
过 程 的 返回 结果 ;最 后 返回 _reply 中 的 数据 。 








Proxy#addBook 


这 个 方法 运行 在 客户 端 ， 它 的 执行 过 程 和 getBookList 是 一 样 的 ， 
addBook 没 有 返回 值 ， 所 以 它 不 需要 从 _reply 中 取出 返回 值 。 


通过 上 面 的 分 析 ， 读 者 应 该 已 经 了 解 了 Binder 的 工作 机 制 ， 但 是 有 
两 点 还 是 需要 额外 说 明 一 下 : 首先 ， 当 客户 端 发 起 远程 请 求 时 ， 由 于 当 
前 线程 会 被 挂 起 直至 服务 端 进程 返回 数据 ， 所 以 如 果 一 个 远程 方法 是 很 
耗 时 的 ， 那 么 不 能 在 UI 线 程 中 发 起 此 远程 请 求 ;， 其 次 ， 由 于 服务 端的 
Binder 方 法 运行 在 Binder 的 线程 池 中 ， 所 以 Binder 方 法 不 管 是 否 耗 时 都 应 
该 采用 同步 的 方式 去 实现 ， 因 为 它 已 经 运行 在 一 个 线程 中 了 。 为 了 更 好 
地 说 明 Binder， 下 面 给 出 一 个 Binder 的 工作 机 制图 ， 如 图 2-5 所 示 。 
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图 2-5 Binder 的 工作 机 制 


从 上 述 分 析 过 程 来 看 ， 我 们 完全 可 以 不 提供 AIDL 文 件 即 可 实现 
Binder， 之 所 以 提供 AIDL 文 件 ， 是 为 了 方便 系统 为 我 们 生成 代码 。 系 统 


根据 AIDL 文 件 生成 Java 文 件 的 格式 是 固定 的 ， 我 们 可 以 抛 开 AIDL 文 件 
直接 写 一 个 Binder 出 来 ， 接 下 来 我 们 就 介绍 如 何 手 动 写 一 个 Binder。 还 
是 上 面 的 例子 ， 但 是 这 次 我 们 不 提供 AIDL 文 件 。 参 考 上 面 系统 上 自动 生 
成 的 IBookManager.java 这 个 类 的 代码 ， 可 以 发 现 这 个 类 是 相当 有 规律 
的 ， 根 据 它 的 特点 ， 我 们 完全 可 以 自己 写 一 个 和 它 一 模 一 样 的 类 出 来 ， 
然后 这 个 不 借助 AIDL 文 件 的 Binder 就 完成 了 。 但 是 我 们 发 现 系统 生成 的 
类 看 起 来 结构 不 清晰 ， 我 们 想 试 着 对 它 进行 结构 上 的 调整 ， 可 以 发 现 这 
个 类 主要 由 两 部 分 组 成 ， 首 先 它 本 号 是 一 个 Binder 的 接口 〈 继 承 了 
IInterface) ， 其 次 它 的 内 部 由 个 Stub 类 ， 这 个 类 就 是 个 Binder。 还 记得 
我 们 怎么 写 一 个 Binder 的 服务 端 吗 ?代码 如 下 所 示 。 

















private final IBookManager.Stub mBinder = new IBookManager.St 
@Override 
public List<Book> getBookList() throws RemoteException { 
synchronized (mBookList) { 


return mBookList; 


J 
@Override 
public void addBook(Book book) throws RemoteException { 
synchronized (mBookList) { 
if (!mBookList.contains(book)) { 


mBookList.add(book); 


首先 我 们 会 实现 一 个 创建 了 一 个 Stub 对 象 并 在 内 部 实现 
IBookManager 的 接口 方法 ， 然 后 在 Service 的 onBind 中 返回 这 个 Stub 对 
象 。 因 此 ， 从 这 一 点 来 看 ， 我 们 完全 可 以 把 Stub 类 提取 出 来 直接 作为 一 
个 独立 的 Binder 类 来 实现 ， 这 样 IBookManager 中 就 只 剩 接口 本 身 了 ， 通 
过 这 种 分 离 的 方式 可 以 让 它 的 结构 变 得 清晰 点 。 


根据 上 面 的 思想 ， 手 动 实 现 一 个 Binder 可 以 通过 如 下 步骤 来 完成 : 


(1) 声明 一 个 AIDL 性 质 的 接口 ， 只 需要 继承 IInterface 接 口 即 可 ， 
IInterface 接 口中 只 有 一 个 asBinder 方 法 。 这 个 接口 的 实现 如 下 : 


public interface IBookManager extends IInterface { 
static final String DESCRIPTOR = "com.ryg.chapter_2.manu 
IBookManager"; 
static final int TRANSACTION _getBookList = IBinder.FIRST. 
CTION + O; 
static final int TRANSACTION_addBook = IBinder.FIRST_CAL 
ale 
public List<Book> getBookList() throws RemoteException; 
public void addBook(Book book) throws RemoteException; 


} 


可 以 看 到 ， 在 接口 中 声明 了 一 个 Binder 描 述 符 和 另外 两 个 id， 这 两 
个 id 分 别 表 示 的 是 getBookList 和 addBook 方 法 ， 这 段 代 码 原 本 也 是 系统 
生成 的 ， 我 们 仿照 系统 生成 的 规则 去 手动 书写 这 部 分 代码 。 如 果 我 们 有 
三 个 方法 ， 应 该 怎么 做 呢 ? 很 显然 ， 我 们 要 再 声明 一 个 id， 然 后 按照 固 
定 模式 声明 这 个 新 方法 即 可 ， 这 个 比较 好 理解 ， 不 再 多 说 。 


(2) 实现 Stub 类 和 Stub 类 中 的 Proxy 代 理 类 ， 这 段 代码 我 们 可 以 自 
已 写 ， 但 是 写 出 来 后 会 发 现 和 系统 自动 生成 的 代码 是 一 样 的 ， 因 此 这 个 
stub 类 我 们 只 需要 参考 系统 生成 的 代码 即 可 ， 只 是 结构 上 需要 做 一 下 调 
整 ， 调 整 后 的 代码 如 下 所 示 。 














mRemote. transact (TRANSACTION_addBook, data, re 
reply. readException(); 

} finally { 
reply.recycle(); 


data.recycle(); 


} 





通过 将 上 述 代 码 和 系统 生成 的 代码 对 比 ， 可 以 发 现 简 直 是 一 模 一 样 
的 。 也 许 有 人 会 问 : 既然 和 系统 生成 的 一 模 一 样 ， 那 我 们 为 什么 要 手动 
去 写 呢 ? 我 们 在 实际 开发 中 完全 可 以 通过 AIDL 文 件 让 系统 去 自动 生 
成 ， 手 动 去 写 的 意义 在 于 可 以 让 我 们 更 加 理解 Binder 的 工作 原理 ， 同 时 
也 提供 了 一 种 不 通过 AIDL 文 件 来 实现 Binder 的 新 方式 。 也 就 是 说 ， 
AIDL 文 件 并 不 是 实现 Binder 的 必需 品 。 如 果 是 我 们 手写 的 Binder， 那 么 
在 服务 端 只 需要 创建 一 个 BookManagerImpl 的 对 象 并 在 Service 的 onBind 
方法 中 返回 即 可 。 最 后 ， 是 人 否 手 动 实现 Binder 没 有 本 质 区 别 ， 二 者 的 工 
作 原 理 完全 一 样 ，AIDL 文 件 的 本 质 是 系统 为 我 们 提供 了 一 种 快速 实现 
Binder 的 工具 ， 仅 此 而 已 。 








接 下 来 ， 我 们 介绍 Binder 的 两 个 很 重要 的 方法 linkToDeath 和 
unlinkToDeath。 我 们 知道 ，Binder 运 行 在 服务 端 进程 ， 如 果 服 务 端 进程 
由 于 某 种 原因 异常 终止 ， 这 个 时 候 我 们 到 服务 端的 Binder 连 接 断 裂 ( 称 
之 为 Binder 死 亡 )， 会 导致 我 们 的 远程 调用 失败 。 更 为 关键 的 是 ， 如 果 
我 们 不 知道 Binder 连 接 已 经 断裂， 那么 客户 端的 功能 就 会 受到 影响 。 为 
了 解决 这 个 问题 ，Binder 中 提供 了 两 个 配对 的 方法 linkToDeath 和 


unlinkToDeath， 通 过 linkToDeath 我 们 可 以 给 Binder 设 置 一 个 死亡 代理 ， 
当 Binder 死 亡 时 ， 我 们 束 会 收 到 通知 ， 这 个 时 候 我 们 就 可 以 重新 发 起 连 
接 请 求 从 而 恢复 连接 。 那 么 到 底 如 何 给 Binder 设 置 死 亡 代理 呢 ? 也 很 简 


FA 


首先 ， 声 明 一 个 DeathRecipient 对 象 。DeathRecipient 是 一 个 接口 ， 





其 内 部 只 有 一 个 方法 binderDied， 我 们 需要 实现 这 个 方法 ， 当 Binder 死 
亡 的 时 候 ， 系 统 就 会 回调 binderDied 方 法 ， 然 后 我 们 就 可 以 移出 之 前 绑 
定 的 binder 代 理 并 重新 绑 定 远程 服务 : 


F 


private IBinder.DeathRecipient mDeathRecipient = new IBinder. 
Recipient() { 
@Override 
public void binderDied() { 
if (mBookManager == null) 
return; 
mBookManager .asBinder().unlinkToDeath(mDeathRecip 


mBookManager = null; 





// TODO: 这 里 重新 绑 定 远程 Service 


其 次 ， 在 客户 器 绑 定 远程 服务 成 功 后 ， 给 binder 设 置 死 亡 代理 : 


mService = IMessageBoxManager .Stub.asInterface(binder ); 


binder .1linkToDeath(mDeathRecipient, 0); 


其 中 linkToDeath 的 第 二 个 参数 是 个 标记 位 ， 我 们 直接 设 为 0 即 可 。 


Zeit LPS, wea eI Emer 了 死亡 代理 ， 当 Binder 死 亡 
的 时 候 我 们 就 可 以 收 到 通知 了 。 男 外 ， 通 过 Binder 的 方法 isBinderAlive 
也 可 以 判断 Binder 是 否 死 亡 。 


到 这 里 ，IPC 的 基础 知识 就 介绍 完毕 了 ， 下 面 开始 进入 正题 ， 直 面 
形形色色 的 进程 间 通 信 方 式 。 


2.4 Android 中 的 IPC 方 式 


在 上 市 中 ， 我 们 介绍 了 IPC 的 几 个 基础 知识 ， 序列 化 和 Binder， 本 
节 开 始 详 细 分 析 各 种 跨 进 程 通信 方式 。 具 体 方式 有 很 多 ， 比 如 可 以 通过 
在 Intent 中 附加 extras 来 传递 信息 ， 或 者 通过 共享 文件 的 方式 来 共享 数 
据 ， 还 可 以 采用 Binder 方 式 来 跨 进 程 通信 ， 男 外 ，ContentProvider 天 生 
就 是 文 持 跨 进程 访问 的 ， 因 此 我 们 也 可 以 采用 它 来 进行 IPC。 此 外 ， 通 
过 网 络 通信 也 是 可 以 实现 数据 传递 的 ， 所 以 Socket 也 可 以 实现 IPC。 上 
述 所 说 的 各 种 方法 都 能 实现 IPC， 它 们 在 使 用 方法 和 侧重 点 上 都 有 很 大 
的 区 别 ， 下 面 会 一 一 进行 展开 。 














2.4.1 使 用 Bundle 


我 们 知道 ， 四 大 组 件 中 的 三 大 组 件 (Activity、Service、Receiver) 
都 是 文 持 在 Intent 中 传递 Bundle 数 据 的 ， 由 于 Bundle 实 现 了 Parcelable 接 
口 ， 所 以 它 可 以 方便 地 在 不 同 的 进程 间 传 输 。 基 于 这 一 点 ， 当 我 们 在 一 
个 进程 中 启动 了 另 一 个 进程 的 Activity、Service 和 Receiver， 我 们 就 可 以 
在 Bundle 中 附加 我 们 需要 传输 给 远程 进程 的 信息 并 通过 Intent 发 送出 
去 。 当 然 ， 我 们 传输 的 数据 必须 能 够 被 序列 化 ， 比 如 基本 类 型 、 实 现 了 
Parcellable 接 口 的 对 象 、 实 现 了 Serializable 接 口 的 对 象 以 及 一 些 Android 
支持 的 特殊 对 象 ， 具 体内 容 可 以 看 Bundle 这 个 类 ， 就 可 以 看 到 所 有 它 支 
持 的 类 型 。Bundle 不 文 持 的 类 型 我 们 无 法 通过 它 在 进程 间 传 递 数 据 ， 这 
个 很 简单 ， 就 不 再 详细 介绍 了 。 这 是 一 种 最 简单 的 进程 间 通 信 方 式 ， 





除了 下 接 传递 数据 这 种 典型 的 使 用 场景 ， 它 还 有 一 种 特殊 的 使 用 场 








景 。 比 如 A 进 程 正在 进行 一 个 计算 ， 计 算 完 成 后 它 要 局 动 B 进 程 的 一 个 

组 件 并 把 计算 结果 传递 给 B 进 程 ， 可 是 遗憾 的 是 这 个 计算 结果 不 文 持 放 
入 Bundle 中 ， 因 此 无 法 通过 Intent 来 传输 ， 这 个 时 候 如 果 我 们 用 其 他 IPC 
方式 束 会 略 显 复杂 。 可 以 考虑 如 下 方式 : 我 们 通过 Intent 启 动 进程 B 的 一 
个 Service 组 件 〈 比 如 IntentService) ， 让 Service 在 后 台 进 行 计算 ， 计算 

完毕 后 再 局 动 B 进 程 中 真正 要 启动 的 目标 组 件 ， 由 于 Service 也 运行 在 B 

进程 中 ， 所 以 目标 组 件 就 可 以 直接 获取 计算 结果 ， 这 样 一 来 就 轻松 解决 
了 跨 进程 的 问题 。 这 种 方式 的 核心 思想 在 于 将 原本 需要 在 A 进程 的 计算 
任务 转移 到 B 进 程 的 后 台 Service 中 去 执行 ， 这 样 就 成 功 地 避免 了 进程 间 
通信 问题 ， 而 且 只 用 了 很 小 的 代价 。 


2.4.2 ”使 用 文件 共 至 


共享 文件 也 是 一 种 不 错 的 进程 间 通 信 方 式 ， 两 个 进程 通过 读 / 写 同 
一 个 文件 来 交换 数据 ， 比 如 A 进程 把 数据 写 入 文件 ，B 进 程 通过 读 取 这 
个 文件 来 获取 数据 。 我 们 知道 ， 在 Windows 上 ， 一 个 文件 如 果 被 加 了 排 
斥 锁 将 会 导致 其 他 线程 无 法 对 其 进行 访问 ， 包 括 读 和 写 ， 而 由 于 
Android 系 统 基于 Linux， 使 得 其 并 发 读 / 写 文件 可 以 没有 限制 地 进行 ， 甚 
至 两 个 线程 同时 对 同一 个 文件 进行 写 操作 都 是 允许 的 ， 尺 管 这 可 能 出 问 
题 。 通 过 文件 交换 数据 很 好 使 用 ， 除 了 可 以 交换 一 些 文本 信息 外 ， 我 们 
还 可 以 序列 化 一 个 对 象 到 文件 系统 中 的 同时 从 另 一 个 进程 中 恢复 这 个 对 
象 ， 下 面 就 展示 这 种 使 用 方法 。 




















还 是 本 章 刚 开始 的 那个 例子 ， 这 次 我 们 在 MainActivity 的 onResume 
中 序列 化 一 个 User 对 象 到 sd 卡 上 的 一 个 文件 里 ， 然 后 在 SecondActivity 的 
onResume 中 去 反 序 列 化 ， 我 们 期 望 在 SecondActivity 中 能 够 正确 地 恢复 


User 对 象 的 值 。 关 键 代 码 如 下 : 





下 面 看 一 下 log， 很 显然 ， 在 SecondActivity 中 成 功 地 从 文件 从 恢复 





了 之 前 存储 的 User 对 象 的 内 容 ， 这 里 之 所 以 说 内 容 ， 是 因为 反 序 列 化 得 
到 的 对 象 只 是 在 内 容 上 和 序列 化 之 前 的 对 象 是 一 样 的 ， 但 它们 本 质 上 还 
是 两 个 对 象 。 





D/MainActivity(10744): persist user:User:{userId:1, userName:h 
isMale:false},with child: {null} 
D/SecondActivity(10877): recover user:User:{userId:1, userName 


isMale:false},with child: {null} 








通过 文件 共享 这 种 方式 来 共享 数据 对 文件 格式 是 没有 有 具体 要 求 的 ， 
比如 可 以 是 文本 文件 ， 也 可 以 是 XML 文件 ， 只 要 读 / 写 双方 约定 数据 格 
式 即 可 。 通 过 文件 共享 的 方式 也 是 有 局 限 性 的 ， 比 如 并 发 读 / 写 的 问 
题 ， 像 上 面 的 那个 例子 ， 如 果 并 发 读 / 写 ， 那 么 我 们 读 出 的 内 容 就 有 可 
能 不 是 最 新 的 ， 如 果 是 并 发 写 的话 那 就 更 严重 了 。 因 此 我 们 要 尽量 避免 
并 发 写 这 种 情况 的 发 生 或 者 考虑 使 用 线程 同步 来 限制 多 个 线程 的 与 操 
作 。 通 过 上 面 的 分 析 ， 我 们 可 以 知道 ， 文 件 共享 方式 适合 在 对 数据 同步 
要 求 不 高 的 进程 之 间 进 行 通信 ， 并 且 要 妥善 处 理 并 发 读 / 写 的 问题 。 














当然 ，SharedPreferences 是 个 特例 ， 众 所 周知 ，SharedPreferences 是 
Android 中 提供 的 轻 量 级 存储 方案 ， 它 通过 键 值 对 的 方式 来 存储 数据 ， 
在 底层 实现 上 它 采 用 XML 文件 来 存储 键 值 对 ， 每 个 应 用 的 
SharedPreferences 文 件 都 可 以 在 当前 包 所 在 的 data 目 录 下 查看 到 。 一 般 来 
说 ， 它 的 目录 位 于 /data/data/package name/shared_prefs 目 录 下 ， 其 中 
package name 表 示 的 是 当前 应 用 的 包 名 。 从 本 质 上 来 说 ， 
SharedPreferences 也 属于 文件 的 一 种 ， 但 是 由 于 系统 对 它 的 读 / 写 有 一 定 
的 缓存 策略 ， 即 在 内 存 中 会 有 一 份 SharedPreferences 文 件 的 缓存 ， 因 此 
在 多 进程 模式 下 ， 系 统 对 它 的 读 / 写 就 变 得 不 可 靠 ， 当 面 对 高 并 发 的 读 / 
写 访问 ，Sharedpreferences 有 很 大 几率 会 丢失 数据 ， 因 此 ， 不 建议 在 进 











程 间 通信 中 使 用 SharedPreferences。 


2.4.3 1% H Messenger 


Messenger") 以 翻译 为 信使 ， 顾 名 思 义 ， 通 过 它 可 以 在 不 同 进程 中 
传递 Message 对 象 ， 在 Message 中 放 入 我 们 需要 传递 的 数据 ， 束 可 以 轻松 
地 实现 数据 的 进程 间 传 递 了 。Messenger 是 一 种 轻 量 级 的 IPC 方 案 ， 它 的 
底层 实现 是 AIDL， 为 什么 这 么 说 昵 ， 我 们 大 致 看 一 下 Messenger 这 个 类 
的 构造 方法 就 明白 了 。 下 面 是 Messenger 的 两 个 构造 方法 ， 从 构造 方法 
的 实现 上 我 们 可 以 明显 看 出 AIDEL 的 痕迹 ， 不 管 是 IMessenger 还 是 
Stub.asInterface， 这 种 使 用 方法 都 表明 它 的 底层 是 AIDL。 








public Messenger(Handler target) { 
mTarget = target.getIMessenger(); 
Í 
public Messenger (IBinder target) { 
mTarget = IMessenger.Stub.asInterface(target); 


} 


Messenger 的 使 用 方法 很 简单 ， 它 对 AIDL 做 了 封装 ， 使 得 我 们 可 以 
更 简便 地 进行 进程 间 通 信 。 同 时 ， 由 于 它 一 次 处 理 一 个 请 求 ， 因 此 在 服 
务 端 我 们 不 用 考虑 线程 同步 的 问题 ， 这 是 因为 服务 端 中 不 存在 并 发 执行 
的 情形 。 实 现 一 个 Messenger 有 如 下 几 个 步骤 ， 分 为 服务 端 和 客户 端 。 
1. 服务 端 进程 


首先 ， 我 们 需要 在 服务 端 创建 一 个 Service 来 处 理 客 户 亲 的 连接 请 


求 ， 同 时 创建 一 个 Handler 并 通过 它 来 创建 一 个 Messenger 对 象 ， 然 后 在 
Service 的 onBind 中 返回 这 个 Messenger 对 象 底层 的 Binder 即 可 。 


2. 客户 端 进程 


客户 端 进程 中 ， 首 先 要 绑 定 服务 端的 Service， 绑 定 成 功 后 用 服务 端 
返回 的 IBinder 对 象 创 建 一 个 Messenger， 通 过 这 个 Messenger 就 可 以 向 服 
务 端 发 送 消 息 了 ， 发 消息 类 型 为 Message 对 象 。 如 果 需 要 服务 端 能 够 回 
应 客户 端 ， 就 和 服务 端 一 样 ， 我 们 还 需要 创建 一 个 Handler 并 创建 一 个 
新 的 Messenger， 并 把 这 个 Messenger 对 象 通过 Message 的 replyTo 参 数 传 
递 给 服务 端 ， 服 务 端 通过 这 个 replyTo 参 数 就 可 以 回应 客户 端 。 这 上 听 起 来 
可 能 还 是 有 点 抽象 ， 不 过 看 了 下 面 的 两 个 例子 ， 读 者 肯定 就 都 明白 了 。 
自 先 ， 我 们 来 看 一 个 简单 点 的 例子 ， 在 这 个 例子 中 服务 端 无 法 回应 客户 


ÙT o 








首先 看 服务 端的 代码 ， 这 是 服务 端的 典型 代码 ， 可 以 看 到 
MessengerHandler 用 来 处 理 客 户 端 发 送 的 消息 ， 并 从 消息 中 取出 客户 端 
发 来 的 文本 信息 。 而 mMessenger 是 一 个 Messenger 对 象 ， 它 和 
MessengerHandler 相 关联 ， 并 在 onBind 方 法 中 返回 它 里 面 的 Binder 对 
象 ， 可 以 看 出 ， 这 里 Messenger 的 作用 是 将 客户 端 发 送 的 消息 传递 给 
MessengerHandler 处 理 。 








public class MessengerService extends Service { 
private static final String TAG = "MessengerService"; 
private static class MessengerHandler extends Handler { 
@Override 
public void handleMessage(Message msg) { 


switch (msg.what) { 





然后 ， 注 册 service， 让 其 运行 在 单独 的 进程 中 : 





接 下 来 再 看 看 客户 端的 实现 ， 客 户 端的 实现 也 比较 简单 ， 首 先 需 要 
绑 定 远程 进程 的 MessengerService， 绑 定 成 功 后 ， 根 据 服务 端 返回 的 
binder 对 象 创建 Messenger 对 象 并 使 用 此 对 象 回 服务 端 发 送 消息 。 下 面 的 
代码 在 Bundle 中 向 服务 端 发 送 了 一 句 话 ， 在 上 面 的 服务 端 代码 中 会 打印 
出 这 人 句 话 。 


public class MessengerActivity extends Activity { 
private static final String TAG = " MessengerActivity"; 
private Messenger mService; 
private ServiceConnection mConnection = new ServiceConne 
public void onServiceConnected(ComponentName classNa 
service) { 
mService = new Messenger (service); 
Message msg = Message.obtain(null,MyConstants.MS 
Bundle data = new Bundle(); 
data.putString("msg", "hello, this is client."); 
msg.setData(data); 
try { 
mService.send(msg); 
} catch (RemoteException e) { 


e.printStackTrace(); 


} 
} 
public void onServiceDisconnected(ComponentName clas 
t 
}; 
@Override 


protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_messenger ); 
Intent intent = new Intent(this,MessengerService.cla 


bindService(intent, mConnection, Context .BIND_AUTO_CRE 


@Override 
protected void onDestroy() { 
unbindService(mConnection) ; 


super.onDestroy()j; 


} 


最 后 ， 我 们 运行 程序 ， 看 一 下 log， 很 显然 ， 服 务 端 成 功 收 到 了 客 
户 端 所 发 来 的 问候 语 : “hello,this is client.”。 


I/MessengerService( 1037): receive msg from Client:hello, this 


通过 上 面 的 例子 可 以 看 出 ， 在 Messenger 中 进行 数据 传递 必须 将 数 
据 放 入 Message 中 ， 而 Messenger 和 Message 都 实现 了 Parcelable 接 口 ， 
此 可 以 跨 进 程 传输 。 简 单 来 说 ，Message 中 所 支持 的 数据 类 型 就 是 
Messenger 所 文 持 的 传输 类 型 。 实 际 上 ， 通 过 Messenger 来 传输 Message， 
Message 中 能 使 用 的 载体 只 有 what、arg1、arg2、Bundle 以 及 replyTo。 
Message 中 的 另 一 个 字段 object 在 同一 个 进程 中 是 很 实用 的 ， 但 是 在 进程 
间 通 信 的 时 候 ， 在 Android ”2.2 以 前 object 字 上 段 不 支持 跨 进程 传输 ， 即 便 
是 2.2 以 后 ， 也 仅仅 是 系统 提供 的 实现 了 Parcelable 接 口 的 对 象 才能 通过 
它 来 传输 。 这 就 意味 着 我 们 上 自 定 义 的 Parcelable 对 象 是 无 法 通过 object 字 
段 来 传输 的 ， 读 者 可 以 试 一 下 。 非 系统 的 Parcelable 对 象 的 确 无 法 通过 
object 字 段 来 传输 ， 这 也 导致 了 object 字 有 段 的 实用 性 大 大 降低 ， 所 幸 我 们 
还 有 Bundle，Bundle 中 可 以 支持 大 量 的 数据 类 型 。 











上 面 的 例子 演示 了 如 何在 服务 站 接收 客户 端 中 发 送 的 消息 ， 但 是 有 
时 候 我 们 还 需要 能 回应 客户 器 ， 下 面 就 介绍 如 何 实现 这 种 效果 。 还 是 采 
用 上 面 的 例子 ， 但 是 稍微 做 一 下 修改 ， 每 当 客 户 端 发 来 一 条 消 轧 ， 服 务 














端 就 会 自动 回复 一 条 “ 嗯 ， 你 的 消息 我 已 经 收 到 ， 稍 后 会 回复 你 。”， 这 
很 类 似 邮 箱 的 自动 回复 功能 。 


首先 看 服务 端的 修改 ， 服 务 端 只 需要 修改 MessengerHandler， 当 收 
到 消息 后 ， 会 立即 回复 一 条 消息 给 客户 端 。 








接着 再 看 客户 端的 修改 ， 为 了 接收 服务 端的 回复 ， 客 户 端 也 需要 准 
备 一 个 接收 消息 的 Messenger 和 Handler， 如 下 所 示 。 





除了 上 述 修改 ， 还 有 很 关键 的 一 点 ， 当 客户 端 发 送 消息 的 时 候 ， 需 
要 把 接收 服务 端 回复 的 Messenger 通 过 Message 的 replyTo 参 数 传 递 给 服务 
端 ， 如 下 所 示 。 


Message msg = Message.obtain(null,MyConstants.MSG_FROM_CLIENT 
Bundle data = new Bundle(); 
data.putString("msg", "hello, this is client."); 
msg.setData(data); 
// 注 意 下 面 这 名 
msg.replyTo = mGetReplyMessenger; 
try { 
mService.send(msg); 
} catch (RemoteException e) { 


e.printStackTrace(); 


通过 上 述 修改 ， 我 们 再 运行 程序 ， 然 后 看 一 下 log， 很 显然 ， 客 户 
端 收 到 了 服务 问 的 回复 “ 嗯 ， 你 的 消息 我 已 经 收 到 ， 稍 后 会 回复 你 。” 
这 说 明 我 们 的 功能 已 经 完成 。 


I/MessengerService( 1419): receive msg from Client:hello,this 


I/MessengerActivity( 1404): receive msg from Service: 咽 ,你 的 消 





到 这 里 ， 我 们 已 经 把 采用 Messenger 进 行进 程 间 通 信 的 方法 都 介绍 
完了 ， 读 者 可 以 试 着 通过 Messenger 来 实现 更 复杂 的 路 进程 通信 功能 。 
下 面 给 出 一 张 Messenger 的 工作 原理 图 以 方便 读者 更 好 地 理解 
Messenger， 如 图 2-6 所 示 。 











图 2-6 Messenger 的 工作 原理 





关于 进程 间 通 信 ， 可 能 有 的 读者 会 觉得 笔者 提供 的 示例 部 是 针对 同 
一 个 应 用 的 ， 有 没有 针对 不 同 应 用 的 ? 是 这 样 的 ， 之 所 以 选择 在 同一 个 
应 用 内 进行 进程 间 通 信 ， 古 因为 操作 起 来 比较 方便 ， 但 古 效 末 和 在 两 个 
应 用 间 进 行进 程 间 通 信和 是 一 样 的 。 在 本 章 刚 开始 就 说 过 ， 同 一 个 应 用 的 
不 同 组 件 ， 如 果 它 们 运行 在 不 同 进 程 中 ， 那 么 和 它们 分 别 属于 两 个 应 用 
没有 本 质 区 别 ， 关 于 这 点 需要 深刻 理解 ， 因 为 这 是 理解 进程 间 通 信 的 基 
础 。 











2.4.4 ”使 用 AIDL 


上 一 节 我 们 介绍 了 使 用 Messenger 来 进行 进程 间 通 信和 的 方法 ， 可 以 
发 现 ，Messenger 是 以 串 行 的 方式 处 理 客户 端 发 来 的 消息 ， 如 果 大 量 的 
消息 同时 发 送 到 服务 端 ， 服 务 端 仍然 只 能 一 个 个 处 理 ， 如 条 有 大 量 的 并 
发 请 求 ， 那 么 用 Messenger 就 不 太 合 适 了 。 同 时 ，Messenger 的 作用 主要 
是 为 了 传递 消息 ， 很 多 时 候 我 们 可 能 需要 跨 进 程 调用 服务 端的 方法 ， 这 
种 情形 用 Messenger 就 无 法 做 到 了 ， 但 是 我 们 可 以 使 用 AIDL 来 实现 跨 进 
程 的 方法 调用 。AIDL 也 是 Messenger 的 底层 实现 ， 因 此 Messenger 本 质 上 
也 是 AIDL， 只 不 过 系统 为 我 们 做 了 封装 从 而 方便 上 层 的 调用 而 已 。 在 








上 一 节 中 ， 我 们 介绍 了 Binder 的 概念 ， 大 家 对 Binder 也 有 了 一 定 的 了 
解 ， 在 Binder 的 基础 上 我 们 可 以 更 加 容易 地 理解 AIDL。 这 里 先 介绍 使 用 
AIDL 来 进行 进程 间 通 信 的 流程 ， 分 为 服务 端 和 客户 端 两 个 方面 。 





1. 服务 站 


服务 端 首 先 要 创建 一 个 Service 用 来 监听 客户 端的 连接 请 求 ， 然 后 创 
建 一 个 AIDL 文 件 ， 将 暴露 给 客户 端的 接口 在 这 个 AIDL 文 件 中 声明 ， 最 
后 在 Service 中 实现 这 个 AIDL 接 口 即 可 。 


2. 客户 端 


客户 端 所 要 做 事情 就 稍微 简单 一 些 ， 首 先 需 要 绑 定 服务 端的 
Service， 绑 定 成 功 后 ， 将 服务 端 返 回 的 Binder 对 象 转 成 AIDL 接 口 所 属 的 
类 型 ， 接 着 就 可 以 调用 AIDL 中 的 方法 了 。 








上 面 描述 的 只 是 一 个 感性 的 过 程 ，AIDL 的 实现 过 程 远 不 止 这 么 简 
单 ， 接 下 来 会 对 其 中 的 细节 和 难点 进行 详细 介绍 ， 并 完善 我 们 在 Binder 
那 一 节 所 提供 的 的 实例 。 


3. AIDEL 接口 的 创建 


首先 看 AIDL 接 口 的 创建 ， 如 下 所 示 ， 我 们 创建 了 一 个 后 级 为 AIDL 
的 文件 ， 在 里 面 声明 了 一 个 接口 和 两 个 接口 方法 。 


// IBookManager .aidl 

package com.ryg.chapter_2.aidl; 
import com.ryg.chapter_2.aidl.Book; 
interface IBookManager { 


List<Book> getBookList(); 


void addBook(in Book book); 
} 


在 AIDL 文 件 中 ， 并 不 是 所 有 的 数据 类 型 都 是 可 以 使 用 的 ， 那 么 到 
底 AIDL 文 件 支 持 哪 些 数 据 类 型 呢 ? 如 下 所 示 。 





。 基 本 数据 类 型 (int、long、char、boolean、double 等 ) ; 

String 和 CharSequence; 

e List: 只 文 持 ArrayList， 里 面 每 个 元 素 都 必须 能 够 被 AIDL 文 持 ; 

e Map: 只 文 持 HashMap， 里 面 的 每 个 元 素 都 必须 被 AIDL 文 持 ， 包 括 
key 和 value; 

Parcelable: 所 有 实现 了 Parcelable 接 口 的 对 象 ; 

AIDL: 所 有 的 AIDL 接 口 本 身 也 可 以 在 AIDL 文 件 中 使 用 。 








以 上 6 种 数据 类 型 就 是 AIDL 所 支持 的 所 有 类 型 ， 其 中 自 定义 的 
Parcelable 对 象 和 AIDL 对 象 必须 要 显 式 import 进 来 ， 不 管 它们 是 否 和 当 
前 的 AIDL 文 件 位 于 同一 个 包 内 。 比 如 IBookManager.aidl 这 个 文件 ， 里 面 
用 到 了 Book 这 个 类 ， 这 个 类 实现 了 Parcelable 接 口 并 且 和 
IBookManager.aidl 位 于 同一 个 包 中 ， 但 是 遵守 AIDL 的 规范 ， 我 们 仍然 需 
要 显 式 地 importj 进 来 : import com.ryg.chapter_2.aidl.Book。AIDL 中 会 大 
量 使 用 到 Parcelable， 至 于 如 何 使 用 Parcelable 接 口 来 序列 化 对 象 ， 在 本 
章 的 前 面 已 经 介绍 过 ， 这 里 就 不 再 歼 述 。 








另外 一 个 需要 注意 的 地 方 是 ， 如 果 AIDL 文 件 中 用 到 了 上 自 定 义 的 
Parcelable 对 象 ， 那 么 必须 新 建 一 个 和 它 同名 的 AIDL 文 件 ， 并 在 其 中 声 
明 它 为 Parcelable 类 型 。 在 上 面 的 IBookManager.aidl 中 ， 我 们 用 到 了 Book 
这 个 类 ， 所 以 ， 我 们 必须 要 创建 Book.aidl， 然 后 在 里 面 添加 如 下 内 容 : 


package com.ryg.chapter_2.aidl; 


parcelable Book; 


我 们 需要 注意 ，AIDL 中 每 个 实现 了 Parcelable 接 口 的 类 都 需要 按照 
上 面 那 种 方式 去 创建 相应 的 AIDL 文 件 并 声明 那个 类 为 parcelable。 除 此 
之 外 ，AIDL 中 除了 基本 数据 类 型 ， 其 他 类 型 的 参数 必须 标 上 方 癌 : in 
out 或 者 inout，in 表 示 输 入 型 参数 ，out 表 示 输 出 型 参数 ，inout 表 示 输 入 
输出 型 参数 ， 至 于 它们 具体 的 区 别 ， 这 个 就 不 说 了 。 我 们 要 根据 实际 需 
要 去 指定 参数 类 型 ， 不 能 一 概 使 用 out 或 者 inout， 因 为 这 在 底层 实现 是 
有 开销 的 。 最 后 ，AIDL 接 口中 只 文 持 方法 ， 不 文 持 声 明 静 态 常量 ， 这 
一 点 区 别 于 传统 的 接口 。 

















为 了 方便 AIDL 的 开发 ， 建 议 把 所 有 和 AIDL 相 关 的 类 和 文件 全 部 放 
入 同一 个 包 中 ， 这 样 做 的 好 处 是 ， 当 客户 端 是 另外 一 个 应 用 时 ， 我 们 可 
以 直接 把 整个 包 复 制 到 客户 端 工 程 中 ， 对 于 本 例 来 说 ， 束 是 要 把 
com.ryg.chapter_2.aidl 这 个 包 和 包 中 的 文件 原封 不 动 地 复制 到 客户 并 
中 。 如 果 AIDL 相 关 的 文件 位 于 不 同 的 包 中 时 ， 那 么 就 需要 把 这 些 包 一 
一 复制 到 客户 端 工 程 中 ， 这 样 操作 起 来 比较 麻烦 而 且 也 容易 出 错 。 需 要 
注意 的 是 ，AIDL 的 包 结 构 在 服务 端 和 客户 端 要 保持 一 致 ， 人 否则 运行 会 
出 错 ， 这 是 因为 客户 端 需要 反 序 列 化 服务 端 中 和 AIDL 接 口 相 关 的 所 有 
类 ， 如 果 类 的 完整 路 径 不 一 样 的 话 ， 束 无 法 成 功 反 序列 化 ， 程 序 也 就 无 
法 正常 运行 。 为 了 方便 演示 ， 本 章 的 所 有 示例 都 是 在 同一 个 工程 中 进行 
的 ， 但 是 读者 要 理解 ， 一 个 工程 和 两 个 工程 的 多 进程 本 质 是 一 样 的 ， 两 
个 工程 的 情况 ， 除 了 需要 复制 AIDL 接 口 所 相关 的 包 到 客户 端 ， 其 他 完 
全 一 样 ， 读 者 可 以 自行 试验 。 








A, 远程 服务 端 Service 的 实现 


上 面 讲述 了 如 何 定 义 AIDL 接 口 ， 接 下 来 我 们 就 需要 实现 这 个 接口 
了 。 我 们 先 创建 一 个 Service， 称 为 BookManagerService， 代 码 如 下 : 





} 





上 面 是 一 个 服务 端 Service 的 典型 实现 ， 首 先 在 onCreate 中 初始 化 添 
加 了 两 本 图 书 的 信息 ， 然 后 创建 了 一 个 Binder 对 象 并 在 onBind 中 返回 
它 ， 这 个 对 象 继承 自 IBookManager.Stub 并 实现 了 它 内 部 的 AIDL 方 法 ， 
这 个 过 程 在 Binder 那 一 节 已 经 介绍 过 了 ， 这 里 就 不 多 说 了 。 这 里 主要 看 
getBookList 和 addBook 这 两 个 AIDL 方 法 的 实现 ， 实 现 过 程 也 比较 简单 ， 
注意 这 里 采用 了 CopyOnWriteArrayList， 这 个 CopyOnWriteArrayList 支 持 
并 发 读 / 写 。 在 前 面 我 们 提 到 ，AIDL 方 法 是 在 服务 端的 Binder 线 程 池 中 
执行 的 ， 因 此 当 多 个 客户 端 同时 连接 的 时 候 ， 会 存在 多 个 线程 同时 访问 
的 情形 ， 所 以 我 们 要 在 AIDL 方 法 中 处理 线程 同步 ， 而 我 们 这 里 直接 使 
用 CopyOnWriteArrayList 来 进行 自动 的 线程 同步 。 


前 面 我 们 提 到 ，AIDL 中 能 够 使 用 的 List 只 有 ArrayList， 但 是 我 们 这 
里 却 使 用 了 CopyOnWriteArrayList (注意 它 不 是 继承 自 ArrayList) ， 为 
什么 能 够 正常 工作 呢 ? 这 是 因为 AIDL 中 所 支持 的 是 抽象 的 List， 而 List 
只 是 一 个 接口 ， 因 此 虽然 服务 端 返回 的 是 CopyOnWriteArrayList， 但 是 
在 Binder 中 会 按照 List 的 规范 去 访问 数据 并 最 终 形成 一 个 新 的 ArrayList 传 
递 给 客户 端 。 所 以 ， 我 们 在 服务 端 采 用 CopyOnWriteArrayList 是 完全 可 
以 的 。 和 此 类 似 的 还 有 ConcurrentHashMap， 读 者 可 以 体会 一 下 这 种 转 
换 情 形 。 然 后 我 们 需要 在 XML 中 注册 这 个 Service， 如 下 所 示 。 注 意 
BookManagerService 是 运行 在 独立 进程 中 的 ， 它 和 客户 端的 Activity 不 在 
同一 个 进程 中 ， 这 样 就 构成 了 进程 间 通 信 的 场景 。 








<service 
android: name=".aid1.BookManagerService" 
android: process=":remote" > 


</service> 


5. 2 dm A SKIN 


客户 端的 实现 就 比较 简单 了 ， 首 先 要 绑 定 远程 服务 ， 绑 定 成 功 后 将 
服务 端 返回 的 Binder 对 象 转换 成 AIDL 接 口 ， 然 后 就 可 以 通过 这 个 接口 去 
调用 服务 端的 远程 方法 了 ， 代 码 如 下 所 示 。 





super.onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_book_manager); 
Intent intent = new Intent(this, BookManagerService.c 
bindService(intent, mConnection, Context .BIND_AUTO_CRE. 
} 
@Override 
protected void onDestroy() { 
unbindService(mConnection) ; 


super.onDestroy()j; 


绑 定 成 功 以 后 ， 会 通过 bookManager 去 调用 getBookList 方 法 ， 然 后 
打印 出 所 获取 的 图 书信 息 。 需 要 注意 的 是 ， 服 务 端的 方法 有 可 能 需要 很 
和 久 才 能 执行 完毕 ， 这 个 时 候 下 面 的 代码 就 会 导致 ANR， 这 一 点 是 需要 注 
意 的 ， 后 面 会 再 介绍 这 种 情况 ， 之 所 以 先 这 么 写 是 为 了 让 读者 更 好 地 了 
解 AIDL 的 实现 步 又。 








接着 在 XML 中 注册 此 Activity， 运 行程 序 ，log 如 下 所 示 。 


I/BookManagerActivity(3047): query book list,list type:java.u 
I/BookManagerActivity(3047): query book list:[[bookId:1, bookN 


可 以 发 现 ， 虽 然 我 们 在 服务 端 返 回 的 是 CopyOnWriteArrayList 类 
型 ， 但 是 客户 端 收 到 的 仍然 是 ArrayList 类 型 ， 这 也 证 实 了 我 们 在 前 面 所 
做 的 分 析 。 第 二 行 log 表 明 客 户 端 成 功 地 得 到 了 服务 端的 网 书 列 表 信 


= 


4D o 





这 就 是 一 次 完 完整 整 的 使 用 AIDL 进 行 IPC 的 过 程 ， 到 这 里 相信 读者 
对 AIDL 应 该 有 了 一 个 整体 的 认识 了 ， 但 是 还 没完 ，AIDEL 的 复杂 性 远 不 
止 这 些 ， 下 面 继续 介绍 AIDEL 中 常见 的 一 些 难 点 。 





我 们 接着 再 调用 一 下 另外 一 个 接口 addBook， 我 们 在 客户 端 给 服务 
端 添加 一 本 书 ， 然 后 再 获取 一 次 ， 看 程序 是 否 能 够 正常 工作 。 还 是 上 面 
的 代码 ， 客 户 端 在 服务 连接 后 ， 在 onServiceConnected 中 做 如 下 改动 : 


public void onServiceConnected(ComponentName className, IBinde 
IBookManager bookManager = IBookManager .Stub.asInterface( 
try { 
List<Book> list = bookManager.getBookList(); 
Log.i(TAG, "query book list:" + list.toString()); 
Book newBook = new Book(3,"Android 开 发 艺术 探索 " ) ， 
bookManager .addBook(newBook ) ; 
Log.i(TAG, "add book:" + newBook); 
List<Book> newList = bookManager.getBookList()j; 
Log.i(TAG, "query book list:" + newList.toString() 
} catch (RemoteException e) { 


e.printStackTrace(); 


运行 后 我 们 再 看 一 下 log， 很 显然 ， 我 们 成 功 地 同 服务 端 添 加 了 一 
本 书 “Android 开 发 艺术 探索 ”。 


I/BookManagerActivity( 3148): query book list:[[bookId:1, book 
I/BookManagerActivity( 3148): add book: [bookId:3, bookName: And 


I/BookManagerActivity( 3148): query book list: [[bookId:1, book 


现在 我 们 考虑 一 种 情况 ， 假 设 有 一 种 需求 : A ANI AN SY HS 
询 图 书 列表 了 ， 太 累 了， 于 是 ， 他 去 问 图 书馆 ，“ 当 有 新 书 时 能 不 能 把 
书 的 信息 告诉 我 呢 ? ”。 大 家 应 该 明白 了 ， 这 了 就 是 一 种 典型 的 观察 者 模 
式 ， 每 个 感 兴趣 的 用 户 都 观察 新 书 ， 当 新 书 到 的 时 候 ， 图 书馆 惑 通 知 每 
一 个 对 这 本 书 感 兴趣 的 用 户 ， 这 种 模式 在 实际 开发 中 用 得 很 多 ， 下 面 我 
们 束 来 模拟 这 种 情形 。 首 先 ， 我 们 需要 提供 一 个 AIDL 接 口 ， 每 个 用 户 
都 需要 实现 这 个 接口 并 且 回 网 书馆 申请 新 书 的 提醒 功能 ， 当 然 用 户 也 可 
以 随时 取消 这 种 提醒 。 之 所 以 选择 AIDL 接 口 而 不 是 普通 接口 ， 是 因为 
AIDL 中 无 法 使 用 普通 接口 。 这 里 我 们 创建 一 个 
IOnNewBookArrivedListener.aidl 文 件 ， 我 们 所 期 望 的 情况 是 : 当 服 务 端 
有 新 书 到 来 时 ， 束 会 通知 每 一 个 已 经 申请 提醒 功能 的 用 户 。 从 程序 上 来 
说 束 是 调用 所 有 IOnNew BookArrivedListener 对 象 中 的 
onNewBookArrived 方 法 ， 并 把 新 书 的 对 象 通过 参数 传递 给 客户 端 ， 内 容 
如 下 所 示 。 





package com.ryg.chapter_2.aidl; 
import com.ryg.chapter_2.aid1.Book; 
interface IOnNewBookArrivedListener { 


void onNewBookArrived(in Book newBook) ; 


} 





除了 要 新 加 一 个 AIDL 接 口 ， 还 需要 在 原 有 的 接口 中 添加 两 个 新 方 


法 ， 代 码 如 下 所 示 。 


-> 


package com.ryg.chapter_2.aidl; 


import com.ryg.chapter_2.aid1.Book; 


import com.ryg.chapter_2.aidl.IOnNewBookArrivedListener ; 
interface IBookManager { 

List<Book> getBookList(); 

void addBook(in Book book); 

void registerListener(IOnNewBookArrivedListener listene 


void unregisterListener(IOnNewBookArrivedListener liste 


接着 ， 服 务 端 中 Service 的 实现 也 要 稍微 修改 一 下 ， 主 要 是 Service 中 
IBookManager.Stub 的 实现 ， 因 为 我 们 在 IBookManager 新 加 了 两 个 方法 ， 
所 以 在 IBookManager.Stub 中 也 要 实现 这 两 个 方法 。 同 时 ， 在 
BookManagerService 中 还 开启 了 一 个 线程 ， 每 隔 5s 就 问 书 库 中 增加 一 本 
新 书 并 通知 所 有 感 兴趣 的 用 户 ， 整 个 代码 如 下 所 示 。 





public class BookManagerService extends Service { 
private static final String TAG = "BMS"; 
private AtomicBoolean mIsServiceDestoryed = new AtomicBo 
private CopyOnWriteArrayList<Book> mBookList = new Copy0 
<Book>(); 
private CopyOnwriteArrayList<IOnNewBookArrivedListener> 
= new CopyOnwriteArrayList<IOnNewBookArrivedListener>(); 
private Binder mBinder = new IBookManager.Stub() { 
@Override 
public List<Book> getBookList() throws RemoteExcepti 
return mBookList; 


} 


@Override 











最 后 ， 我 们 还 需要 修改 一 下 客户 端的 代码 ， 主 要 有 两 方面 : 首先 客 
户 端 要 注册 IOnNewBookArrivedListener 到 远程 服务 端 ， 这 样 当 有 新 书 时 
服务 端 才能 通知 当前 客户 端 ， 同 时 我 们 要 在 Activity 退 出 时 解除 这 个 注 
册 ; 男 一 方面 ， 当 有 新 书 时 ， 服 务 端 会 回调 客户 端的 
IOnNewBookArrivedListener 对 象 中 的 onNewBookArrived 方 法 ， 但 是 这 个 
方法 是 在 客户 端的 Binder 线 程 池 中 执行 的 ， 因 此 ， 为 了 便于 进行 UI 操 
作 ， 我 们 需要 有 一 个 Handler 可 以 将 其 切换 到 客户 端的 主线 程 中 去 执 


行 ， 这 个 原理 在 Binder 中 已 经 做 了 分 析 ， 这 里 就 不 多 说 了 。 客 户 端的 代 
码 修改 如 下 : 





Log.i(TAG, "query book list,list type:" 

+ list.getClass().getCanonicalName( ) 
Log.i(TAG, "query book list:" + list.toString 
Book newBook = new Book(3, "Androidi" ) ; 
bookManager .addBook(newBook ) ; 
Log.i(TAG, "add book:" + newBook); 
List<Book> newList = bookManager.getBookList 
Log.i(TAG, "query book list:" + newList.toStr 
bookManager .registerListener (mOnNewBookArriv 

} catch (RemoteException e) { 


e.printStackTrace(); 


$ 


public void onServiceDisconnected(ComponentName clas 
mRemoteBookManager = null; 


Log.e(TAG, "binder died."); 


}; 
private IOnNewBookArrivedListener mOnNewBookArrivedListe 
IOnNewBookArrivedListener.Stub() { 
@Override 
public void onNewBookArrived(Book newBook) throws Re 
mHandler .obtainMessage(MESSAGE_NEW_BOOK_ARRIVED, 


.sendTotarget(); 


Fs 


@Override 


运行 程序 ， 看 一 下 log， 从 log 中 可 以 看 出 ， 客 户 端 的 确 收 到 了 服务 
端 每 5s 一 次 的 新 书 推送 ， 我 们 的 功能 也 就 实现 了 。 





TOnNewBookArrivedListener$Stub$Proxy@4052a648 
D/BookManagerActivity( 3385): receive new book :[bookId:4, boo 
book#4] 

D/BMS(3414) :onNewBookArrived, notify listener:com.ryg.chapter_ 
IOnNewBookArrivedListener$Stub$Proxy@4052a648 
D/BookManagerActivity( 3385): receive new book :[bookId:5, boo 
book#5] 


如 果 你 以 为 到 这 里 AIDL 的 介绍 就 结束 了 ， 那 你 就 错 了 ， 之 前 束 说 
过 ，AIDL 远 不 止 这 么 简单 ， 目 前 还 有 一 些 难 点 是 我 们 还 没有 涉及 的 ， 
接 下 来 将 继续 为 读者 介绍 。 


从 上 面 的 代码 可 以 看 出 ， 当 BookManagerActivity 关 闭 时 ， 我 们 会 在 
onDestroy 中 去 解除 已 经 注册 到 服务 端的 listener， 这 就 相当 于 我 们 不 想 再 
接收 图 书馆 的 新 书 提 醒 了 ， 所 以 我 们 可 以 随时 取消 这 个 提醒 服务 。 按 
back 键 退出 BookManagerActivity， 下 面 是 打印 出 的 log。 


I/BookManagerActivity(5642): unregister listener:com.ryg.chap 
BookManagerActivity$3@405284c8 
D/BMS(5650): not found,can not unregister. 


D/BMS(5650): unregisterListener,current size:1 


从 上 面 的 log 可 以 看 出 ， 程 序 没有 像 我 们 所 预期 的 那样 执行 。 在 解 
注册 的 过 程 中 ， 服 务 端 竟然 无 法 找到 我 们 之 前 注册 的 那个 listener， 在 客 
户 端 我 们 注册 和 解 注册 时 明明 传递 的 古 同一 个 listenerl 阿 ! 最 终 ， 服 务 端 
由 于 无 法 找到 要 解除 的 listener 而 宣告 解 注册 失败 ! 这 当然 不 是 我 们 想 要 
的 结果 ， 但 是 仔细 想 想 ， 好 像 这 种 方式 的 确 无 法 完成 解 注 册 。 其 实 ， 这 
是 必然 的 ， 这 种 解 注册 的 处 理 方式 在 日 常 开发 过 程 中 时 党 使 用 到 ， 但 是 








放 到 多 进程 中 却 无 法 奏效 ， 因 为 Binder 会 把 客户 端 传递 过 来 的 对 象 重 新 
转化 并 生成 一 个 新 的 对 象 。 虽 然 我 们 在 注册 和 解 注 册 过 程 中 使 用 的 是 同 
一 个 客户 器 对 象 ， 但 是 通过 Binder 传 递 到 服务 端 后 ， 却 会 产生 两 个 全 新 
的 对 象 。 别 筷 了 对 象 是 不 能 路 进程 直接 传输 的 ， 对 象 的 路 进程 传输 本 质 
上 都 是 反 序 列 化 的 过 程 ， 这 就 是 为 什么 AIDL 中 的 自 定义 对 象 都 必须 要 
实现 Parcelable 接 口 的 原因 。 那 么 到 底 我 们 该 怎么 做 才能 实现 解 注册 功能 
呢 ? 答案 是 使 用 RemoteCallbackList， 这 看 起 来 很 抽象 ， 不 过 没关系 ， 

请 看 接 下 来 的 详细 分 析 。 





RemoteCallbackList 是 系统 专门 提供 的 用 于 删除 跨 进 程 listener 的 接 
O. Remote-CallbackList 是 一 个 沁 型 ， 文 持 管 理 任意 的 AIDL 接 口 ， 这 点 
从 它 的 声明 就 可 以 看 出 ， 因 为 所 有 的 AIDL 接 口 都 继承 自 IInterface 接 
口 ， 读 者 还 有 印象 吗 ? 





public class RemoteCallbackList<E extends IInterface> 


它 的 工作 原理 很 简单 ， 在 它 的 内 部 有 一 个 Map 结 构 专 门 用 来 保存 所 
有 的 AIDL 回 调 ， 这 个 Map 的 Kkey 是 IBinder 类 型 ，value 是 Callback 类 型 ， 
如 下 所 示 。 


ArrayMap<IBinder,Callback> mCallbacks = new ArrayMap<IBinder, 





其 中 Callback 中 封装 了 真正 的 远程 listener。 当 客户 端 注册 listener 的 
时 候 ， 它 会 把 这 个 listener 的 信息 存 入 mCallbacks 中 ， 其 中 key 和 value 分 
别 通过 下 面 的 方式 获得 : 


IBinder key= listener .asBinder() 


Callback value = new Callback(listener, cookie) 


到 这 里 ， 读 者 应 该 都 明白 了 ， 虽 然 说 多 次 路 进程 传输 客户 端的 同一 
个 对 象 会 在 服务 端 生成 不 同 的 对 象 ， 但 是 这 些 新 生成 的 对 象 有 一 个 共同 
点 ， 那 就 是 它们 底层 的 Binder 对 象 是 同一 个 ， 利 用 这 个 特性 ， 就 可 以 实 
现 上 面 我 们 无 法 实现 的 功能 。 当 客户 端 解 注册 的 时 候 ， 我 们 只 要 授 历 服 
务 端 所 有 的 listener， 找 出 那个 和 解 注 册 listener 具 有 相同 Binder 对 象 的 服 
务 端 listener 并 把 它 删 挥 即 可 ， 这 惑 是 RemoteCallbackList 为 我 们 做 的 事 
情 。 同 时 RemoteCallbackList 还 有 一 个 很 有 用 的 功能 ， 那 耽 是 当 客 户 端 
进程 终止 后 ， 它 能 够 自动 移 除 客户 端 所 注册 的 listener。 另 外 ， 
RemoteCallbackList 内 部 自动 实现 了 线程 同步 的 功能 ， 所 以 我 们 使 用 它 
来 注册 和 人 解 注册 时 ， 不 需要 做 额外 的 线程 同步 工作 。 由 此 可 见 ， 
RemoteCallbackList 的 确 是 个 很 有 价值 的 类 ， 下 面 就 演示 如 何 使 用 它 来 
完成 解 注 册 。 











RemoteCallbackList 使 用 起 来 很 简单 ， 我 们 要 对 BookManagerService 
做 一 些 修改 ， 首 先 要 创建 一 个 RemoteCallbackList 对 象 来 蔡 代 之 前 的 
CopyOnWriteArrayList， 如 下 所 示 。 


private RemoteCallbackList<IOnNewBookArrivedListener> mListen 


RemoteCallbackList<IOnNewBookArrivedListener>(); 


然后 修改 registerListener 和 unregisterListener 这 两 个 接口 的 实现 ， 如 
下 所 示 。 


@Override 
public void registerListener(IOnNewBookArrivedListener listen 
throws RemoteException { 


mListenerList.register(listener); 





怎么 样 ? 是 不 是 用 起 来 很 简单 ， 接 着 要 修改 onNewBookArrived 方 
法 ， 当 有 新 书 时 ， 我 们 就 要 通知 所 有 已 注册 的 listener， 如 下 所 示 。 





BookManagerService 的 修改 已 经 完毕 了 ， 为 了 方便 我 们 验证 程序 的 
功能 ， 我 们 还 需要 添加 一 些 log， 在 注册 和 解 注 册 后 我 们 分 别 打印 出 所 
有 listener 的 数量 。 如 果 程 序 正常 工作 的 话 ， 那 么 注册 之 后 listener 总 数量 








是 1， 解 注册 之 后 总 数量 应 该 是 0(， 我 们 再 次 运行 一 下 程序 ， 看 是 否 如 
此 。 从 下 面 的 log 来 看 ， 很 显然 ， 使 用 RemoteCallbackList 的 确 可 以 完成 
跨 进程 的 解 注册 功能 。 


I/BookManagerActivity(8419): register listener:com.ryg.chapte 
BookManagerActivity$3@40537610 

D/BMS(8427): registerListener,current size:1 
I/BookManagerActivity(8419): unregister listener:com.ryg.chap 
BookManagerActivity$3@40537610 

D/BMS(8427): unregister success. 


D/BMS(8427): unregisterListener,current size:0 


使 用 RemoteCallbackList， 有 一 点 需要 注意 ， 我 们 无 法 像 操 作 List 一 
样 去 操作 它 ， 尽 管 它 的 名 字 中 也 带 个 List， 但 是 它 并 不 是 一 个 List。 过 历 
RemoteCallbackList， 必 须要 按照 下 面 的 方式 进行 ， 其 中 beginBroadcast 
和 beginBroadcast 必 须要 配对 使 用 ， 哪 人 我 们 仅仅 是 想 要 获取 
RemoteCallbackList 中 的 元 素 个 数 ， 这 是 必须 要 注意 的 地 方 。 








final int N = mListenerList.beginBroadcast(); 
Tor (ainme EPSON y e 
IOnNewBookArrivedListener 1 = mListenerList.getBroadcastI 
wF (IL l= mW) {£ 
//TODO handle 1 


} 


mListenerList.finishBroadcast(); 











到 这 里 ，AIDEL 的 基本 使 用 方法 已 经 介绍 完了 ， 但 是 有 几 点 还 需要 
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运行 在 服务 端的 Binder 线 程 池 中 ， 同 时 客户 端 线程 会 被 挂 起 ， 这 个 时 候 
如 末 服 务 疹 方法 执行 比较 耗 时 ， 就 会 导致 客户 问 线程 长 时 间 地 阻 考 在 这 
里 ， 而 如 果 这 个 客户 端 线程 是 UI 线程 的 话 ， 束 会 导致 客户 端 ANR， 这 当 
然 不 是 我 们 想 要 看 到 的 。 因 此 ， 如 果 我 们 明确 知道 某 个 远程 方法 是 耗 时 
的 ， 那 么 惑 要 避免 在 客户 端的 UI 线 程 中 去 访问 远程 方法 。 由 于 客户 问 的 
onServiceConnected 和 onService Disconnected 方 法 都 运行 在 UI 线程 中 ， 所 
以 也 不 可 以 在 它们 里 面 直接 调用 服务 端的 耗 时 方法 ， 这 点 要 尤其 注意 。 
男 外 ， 由 于 服务 端的 方法 本 里 就 运行 在 服务 端的 Binder 线 程 池 中 ， 所 以 
服务 端 方法 本 号 就 可 以 执行 大 量 耗 时 操作 ， 这 个 时 候 切 记 不 要 在 服务 端 
方法 中 开 线程 去 进行 异步 任务 ， 除 非 你 明确 知道 自己 在 干什么 ， 人 否则 不 
建议 这 么 做 。 下 面 我 们 稍微 改造 一 下 服务 端的 getBookList 方 法 ， 我 们 假 
定 这 个 方法 是 耗 时 的 ， 那 么 服务 端 可 以 这 么 实现 ; 








@Override 

public List<Book> getBookList() throws RemoteException { 
SystemClock.sleep(5000) ; 
return mBookList; 


} 
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getBookList 方 法 ， 可 以 预知 ， 连 续 单 击 几 次 ， 客 户 问 就 ANR 了 ， 如 图 2- 
7 所 示 ， 感 兴趣 读者 可 以 自行 试 一 下 。 


Ad BER. 


活动 BookManagerActivity ( 在 
应 用 程序 Chapter 2 中 ) 无 响 
Wo 


量 制 关闭 | 





图 2-7 UI 线程 中 调用 远程 耗 时 方法 导致 的 ANR 


避免 出 现 上 述 这 种 ANR 其 实 很 简单 ， 我 们 只 需要 把 调用 放 在 非 UI 线 


程 即 可 ， 如 下 所 示 。 


public void onButtoniClick(View view) { 
Toast.makeText(this, "click buttoni1",Toast.LENGTH_SHORT).s 
new Thread(new Runnable() { 
@Override 
public void run() { 
if (mRemoteBookManager != null) { 
try { 
List<Book> newList = mRemoteBookManag 
} catch (RemoteException e) { 


e.printStackTrace(); 


} 
}).start(); 








同 理 ， 当 远程 服务 端 需要 调用 客户 端的 listener 中 的 方法 时 ， 被 调用 
的 方法 也 运行 在 Binder 线 程 池 中 ， 只 不 过 是 客户 端的 线程 池 。 上 所以， 我 
们 同样 不 可 以 在 服务 端 中 调用 客户 端的 耗 时 方法 。 比 如 针对 
BookManagerService 的 onNewBookArrived 方 法 ， 如 下 所 示 。 在 它 内 部 调 
用 了 客户 端的 IOnNewBookArrivedListener 中 的 onNewBookArrived 方 法 ， 
如 果 客 户 端的 这 个 onNewBookArrived 方 法 比较 耗 时 的 话 ， 那 么 请 确保 
BookManagerService 中 的 onNewBookArrived 运 行 在 非 UI 线 程 中 ， 和 否则 将 
导致 服务 端 无 法 啊 应 。 


private void onNewBookArrived(Book book) throws RemoteExcepti 


mBookList.add(book); 

Log.d(TAG, "onNewBookArrived, notify listeners:" + mListene 

size()); 

for (int i = 0; i < mListenerList.size(); i++) { 
IOnNewBookArrivedListener listener = mListenerLis 
Log.d(TAG, "onNewBookArrived,notify listener:" + 1 


listener .onNewBookArrived( book) ; 


} 


另外 ， 由 于 客户 端的 IOnNewBookArrivedListener 中 的 
onNewBookArrived 方 法 运行 在 客户 端的 Binder 线 程 池 中 ， 所 以 不 能 在 它 
里 面 去 访问 UI 相 关 的 内 容 ， 如 果 要 访问 UI， 请 使 用 Handler 切 换 到 UI 线 
程 ， 这 一 点 在 前 面 的 代码 实例 中 已 经 有 所 体现 ， 这 里 就 不 再 详细 描述 
is 


为 了 程序 的 健壮 性 ， 我 们 还 需要 做 一 件 事 。Binder 是 可 能 意外 死亡 
的 ， 这 往往 是 由 于 服务 端 进 程 意 外 停止 了 ， 这 时 我 们 需要 重新 连接 服 
务 。 有 两 种 方法 ， 第 一 种 方法 是 给 Binder 设 置 DeathRecipient 监 听 ， 当 
Binder 死 亡 时 ， 我 们 会 收 到 binderDied 方 法 的 回调 ， 在 binderDied 方 法 中 
我 们 可 以 重 连 远程 服务 ， 具 体 方法 在 Binder 那 一 节 已 经 介绍 过 了 ， 这 里 
束 不 再 详细 描述 了 。 男 一 种 方法 是 在 onServiceDisconnected 中 重 连 远程 
服务 。 这 两 种 方法 我 们 可 以 随便 选择 一 种 来 使 用 ， 它 们 的 区 别 在 于 : 
onServiceDisconnected 在 客户 端的 UI 线程 中 被 回调 ， 而 binderDied 在 客户 
端的 Binder 线 程 池 中 被 回调 。 也 就 是 说 ， 在 binderDied 方 法 中 我 们 不 能 
访问 UI， 这 就 是 它们 的 区 别 。 下 面 验证 一 下 二 者 之 间 的 区 别 ， 首 先 我 们 
通过 DDMS 杀 死 服务 端 进 程 ， 接 着 在 这 两 个 方法 中 打印 出 当前 线程 的 名 





称 ， 如 下 所 示 。 


D/BookManagerActivity(13652): onServiceDisconnected. tname:ma 


D/BookManagerActivity(13652): binder died. tname:Binder Threa 


从 上 面 的 log 和 图 2-8 我 们 可 以 看 到 ，onServiceDisconnected 运 行 在 








z x O x O m A 一 /人 一 $ vy x, 
main 线 程 中 ， 即 UI 线程 ， 而 binderDied 运 行 在 “Binder ”Thread#2” 这 个 线 
口 Sf, H \ 三 > H P ~ 口 y TN Si O 
程 中 ， 很 显然 ， 它 是 Binder 线 程 池 中 的 一 个 线程 。 
B® Devices 5% = O | &Threads X G 
+ 0 & B 3 2| & @ ID Tid Status utime stime Name 
v 1 14220 Native 12 4 main 
Name *2 14221 VmWait 0 1 HeapWorker 
a @ htc-htc_a510e-SH1AGTR18501 Online | 3 14222 VmWait : di 
com.fd.httpd 3445 *4 14223 VmWait 0 0 Signal Catcher 
com.iflytek.inputmethod 271 *5 14224 Runnable 2 3 JDWP 
com.ryg.chapter_2 14220 *6 14225 VmWait 0 0 Compiler 
com.ryg.chapter_2:remote 14250 7 14226 Native 0 0 Binder Thread #1 
8 14227 Native 0 0 Binder Thread #2 
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at dalvik.system.NativeStart.run(Native Method) 





图 2-8 


DDMS 中 的 线程 信息 





到 此 为 止 ， 我 们 已 经 对 AIDL 有 了 一 个 系统 性 的 认识 ， 但 是 还 差 最 
后 一 步 : 如 何在 AIDL 中 使 用 权限 验证 功能 。 默 认 情 况 下 ， 我 们 的 远程 





服务 任何 人 都 可 以 连接 ， 但 这 应 该 不 是 我 们 愿意 看 到 的 ， 所 以 我 们 必须 
给 服务 加 入 权限 验证 功能 ， 权 限 验 证 失败 则 无 法 调用 服务 中 的 方法 。 在 


AIDL 中 进行 权限 验证 ， 这 里 介绍 两 种 常用 的 方法 。 





第 一 种 方法 ， 我 们 可 以 在 onBind 中 进行 验证 ， 验 证 不 通过 就 直接 返 
回 null， 这 样 验证 失败 的 客户 端 直接 无 法 绑 定 服务 ， 至 于 验证 方式 可 以 
有 多 种 ， 比 如 使 用 permission 验 证 。 使 用 这 种 验证 方式 ， 我 们 要 先 在 
AndroidMenifest 中 声明 所 需 的 权限 ， 比 如 : 


<permission 
android: name="com.ryg.chapter_2.permission.ACCESS_BOOK_SE 


android: protectionLevel="normal" /> 


关于 permission 的 定义 方式 请 读者 但 看 相关 资料 ， 这 里 就 不 详细 展 
开 了 ， 毕 竟 本 节 的 主要 内 容 是 介绍 AIDL。 就 可 以 在 
BookManagerService 的 onBind 方 法 中 做 权限 验证 了 ， 如 下 所 示 。 


public IBinder onBind(Intent intent) { 
int check = checkCallingOrSelfPermission("com.ryg.chapter. 
permission.ACCESS_ BOOK_SERVICE"); 
if (check == PackageManager.PERMISSION_DENIED) { 
return null; 
i 


return mBinder; 


} 


一 个 应 用 来 绑 定 我 们 的 服务 时 ， 会 验证 这 个 应 用 的 权限 ， 如 果 它 没 
有 使 用 这 个 权限 ，onBind 方 法 就 会 直接 返回 null， ee ee 
无 法 绑 定 到 我 们 的 服务 ， 这 样 就 达到 了 权限 验证 的 效果 ， 这 种 方法 同样 
适用 于 Messenger 中 ， 读 者 可 以 自行 扩展 。 





如 果 我 们 自己 内 部 的 应 用 想 绑 定 到 我 们 的 服务 中 ， 只 需要 在 它 的 
AndroidMenifest 文 件 中 采用 如 下 方式 使 用 permission 即 可 。 


<uses-permission android:name="com.ryg.chapter_2.permission.A 


SERVICE" /> 


第 二 种 方法 ， 我 们 可 以 在 服务 端的 onTransact 方 法 中 进行 权限 验 


证 ， 如 果 验 证 失败 就 直接 返回 false， 这 样 服务 端 就 不 会 终止 执行 AIDL 
中 的 方法 从 而 达到 保护 服务 端的 效果 。 至 于 具体 的 验证 方式 有 很 多 ， 可 
eee ae 具体 实现 方式 和 第 一 种 方法 一 样 。 还 可 以 采用 
Uid 和 Pid 来 做 验证 ， 通 过 getCallingUid 和 getCallingPid 可 以 拿 到 客户 端 所 
属 应 用 的 Uid 和 Pid， 通 过 这 两 个 参数 我 们 可 以 做 一 些 验 证 工作 ， 比 如 验 
证 包 名 。 在 下 面 的 代码 中 ， 既 验证 了 permission， 又 验证 了 包 名 。 一 个 
应 用 如 果 想 远程 调用 服务 中 的 方法 ， 首 先 要 使 用 我 们 的 自 定义 权 

KE “com.ryg.chapter_2.permission. ACCESS BOOK_SERVICE”, KREZ 
必须 以 “com.ryg”" 开 始 ， 否 则 调用 服务 端的 方法 会 失败 。 











public boolean onTransact(int code,Parcel data,Parcel reply,1i 

throws RemoteException { 

int check = checkCallingOrSelfPermission("com.ryg.chapter. 

ACCESS_BOOK_SERVICE" ); 

if (check == PackageManager.PERMISSION_DENIED) { 
return false; 

j 

String packageName = null; 

String[] packages = getPackageManager().getPackagesForUid 

Uid()); 

if (packages != null && packages.length > 0) { 
packageName = packages[0]; 

i 

if (!packageName.startswith("com.ryg")) { 
return false; 

J; 


return super.onTransact (code, data, reply, flags); 


} 





上 上面 介绍 了 两 种 AIDL 中 第 用 的 权限 验证 方法 ， 但 是 肯定 还 有 其 他 
方法 可 以 做 权限 验证 ， 比 如 为 Service 指 定 android:permission 属 性 等 ， 这 
里 就 不 一 一 进行 介绍 了 。 到 这 里 为 止 ， 本 节 的 内 容 就 全 部 结束 了 ， 读 者 
应 该 对 AIDL 的 使 用 过 程 有 很 深入 的 理解 了 ， 接 下 来 会 介绍 男 一 个 IPC 方 
式 ， 那 就 是 使 用 ContentProvider。 





2.4.5 ”使 用 ContentProvider 


ContentProvider 是 Android 中 提供 的 专门 用 于 不 同 应 用 间 进 行 数 据 共 
享 的 方式 ， 从 这 一 点 来 看 ， 它 天 生 就 适合 进程 间 通 信 。 和 Messenger 一 
样 ，ContentProvider 的 底层 实现 同样 也 是 Binder， 由 此 可 见 ，Binder 在 
Android 系 统 中 是 何等 的 重要 。 虽 然 ContentProvider 的 底层 实现 是 
Binder， 但 是 它 的 使 用 过 程 要 比 AIDL 简 单 许多 ， 这 是 因为 系统 已 经 为 我 
们 做 了 封装 ， 使 得 我 们 无 顷 关 心底 层 细节 即 可 轻松 实现 IPC。 
ContentProvider 虽 然 使 用 起 来 很 简单 ， 包 括 目 己 创建 一 个 
ContentProvider 也 不 是 什么 难事 ， 尽 管 如 此 ， 它 的 细节 还 是 相当 多 ， 比 
如 CRUD 操 作 、 防 止 SQL 注 入 和 权限 控制 等 。 由 于 半 市 主题 限制 ， 在 本 
节 中 ， 笔 者 暂时 不 对 ContentProvider 的 使 用 细节 以 及 工作 机 制 进行 详细 
分 析 ， 而 是 为 读者 介绍 采用 ContentProvider 进 行 跨 进 程 通 信 的 主要 流 
程 ， 至 于 使 用 细节 和 内 部 工作 机 制 会 在 后 续 和 章节 进 行 详细 分 析 。 














系统 预 置 了 许多 ContentProvider， 比 如 通讯 录 信 息 、 日 程 表 信 息 
等 ， 要 跨 进 程 访问 这 些 信息 ， 只 需要 通过 ContentResolver 的 query、 
update、insert 和 delete 方 法 即 可 。 在 本 节 中 ， 我 们 来 实现 一 个 自 定义 的 
ContentProvider， 并 演示 如 何在 其 他 应 用 中 获取 ContentProvider 中 的 数 











据 从 而 实现 进程 间 通 信 这 一 目的 。 首 先 ， 我 们 创建 一 个 
ContentProvider， 名 字 就 叫 BookProvider。 创 建 一 个 自 定 义 的 
ContentProvider 很 简单 ， 只 需要 继承 ContentProvider 类 并 实现 六 个 抽象 
方法 即 可 : onCreate、query、update、insert、delete 和 getType。 这 六 个 
抽象 方法 都 很 好 理解 ，onCreate 代 表 ContentProvider 的 创建 ， 一 般 来 说 
我 们 需要 做 一 些 初始 化 工作 ; getType 用 来 返回 一 个 Uri 请 求 所 对 应 的 
MIME 类 型 (媒体 类 型 ) ， 比 如 图 乒 、 视 频 等， 这 个 媒体 类 型 还 是 有 点 
复杂 的 ， 如 果 我 们 的 应 用 不 关注 这 个 选项 ， 可 以 直接 在 这 个 方法 中 返回 
null 或 者 “*/*”， 剩 下 的 四 个 方法 对 应 于 CRUD 操 作 ， 即 实现 对 数据 表 的 
增删 改 查 功能 。 根 据 Binder 的 工作 原理 ， 我 们 知道 这 六 个 方法 均 运 行 在 
ContentProvider 的 进程 中 ， 除 了 onCreate 由 系统 回调 并 运行 在 主线 程 

里 ， 其 他 五 个 方法 均 由 外 界 回 调 并 运行 在 Binder 线 程 池 中 ， 这 一 点 在 接 
下 来 的 例子 中 可 以 再 次 证 明 。 











ContentProvider 主 要 以 表格 的 形式 来 组 织 数 据 ， 并 且 可 以 包含 多 个 
表 ， 对 于 每 个 表格 来 说 ， 它 们 都 具有 行 和 列 的 层次 性 ， 行 往往 对 应 一 条 
记录 ， 而 列 对 应 一 条 记录 中 的 一 个 字段 ， 这 点 和 数据 库 很 类 似 。 除 了 表 
格 的 形式 ，ContentProvider 还 支持 文件 数据 ， 比 如 图 片 、 视 频 等 。 文 件 
数据 和 表格 数据 的 结构 不 同 ， 因 此 处 理 这 类 数据 时 可 以 在 
ContentProvider 中 返回 文件 的 句柄 给 外 界 从 而 让 文件 来 访问 
ContentProvider 中 的 文件 信息 。Android 系 统 所 提供 的 MediaStore 功 能 就 
是 文件 类 型 的 ContentProvider， 详 细 实 现 可 以 参考 MediaStore。 男 外 ， 
虽然 ContentProvider 的 底层 数据 看 起 来 很 像 一 个 SQLite 数 据 库 ， 但 是 
ContentProvider 对 底层 的 数据 存储 方式 没有 任何 要 求 ， 我 们 既 可 以 使 用 
SQLite 数 据 库 ， 也 可 以 使 用 普通 的 文件 ， 甚 至 可 以 采用 内 存 中 的 一 个 对 
象 来 进行 数据 的 存储 ， 这 一 点 在 后 续 的 章节 中 会 再 次 介绍 ， 所 以 这 里 不 
FRA TS 














下 面 看 一 个 最 简单 的 示例 ， 它 演示 了 ContentProvider 的 工作 工程 。 
首先 创建 一 个 BookProvider 类 ， 它 继承 自 ContentProvider 并 实现 了 
ContentProvider 的 六 个 必须 需要 实现 的 抽象 方法 。 在 下 面 的 代码 中 ， 我 
们 什么 都 没 干 ， 尽 管 如 此 ， 这 个 BookProvider 也 是 可 以 工作 的 ， 只 是 它 
无 法 同 外 界 提供 有 效 的 数据 而 已 。 





@Override 

public Uri insert(Uri uri,ContentValues values) { 
Log.d(TAG, "insert"); 
return null; 

} 

@Override 

public int delete(Uri uri,String selection,String[] sele 
Log.d(TAG, "delete"); 
return 0; 

J 

@Override 

public int update(Uri uri,ContentValues values,String se 

String[] selectionArgs) { 

Log.d(TAG, "update"); 


return 0; 


接着 我 们 需要 注册 这 个 BookProvider， 如 下 所 示 。 其 中 
android:authorities 是 Content-Provider 的 唯一 标识 ， 通 过 这 个 属性 外 部 应 
用 就 可 以 访问 我 们 的 BookProvider， 因 此 ，android:authorities 必 须 是 唯一 
的 ， 这 里 建议 读者 在 命名 的 时 候 加 上 包 名 前 级 。 为 了 演示 进程 间 通 信 ， 
我 们 让 BookProvider 运 行 在 独立 的 进程 中 并 给 它 添 加 了 权限 ， 这 样 外 界 
应 用 如 果 想 访问 BookProvider， 就 必须 声明 “com.ryg.PROVIDER” 这 个 权 
限 。ContentProvider 的 权限 还 可 以 细 分 为 读 权 限 和 写 权限 ， 分 别 对 应 
android:readPermission 和 android:writePermission 属 性 ， 如 果 分 别 声 明了 


读 权 限 和 写 权 限 ， 那 么 外 界 应 用 也 必须 依次 声明 相应 的 权限 才 可 以 进行 

















读 / 写 操作 ， 和 否则 外 界 应 用 会 异常 终止 。 关 于 权限 这 一 块 ， 请 读者 自行 
查阅 相关 资料 ， 本 章 不 进行 详细 介绍 。 


<provider 
android: name=".provider .BookProvider" 
android: authorities="com.ryg.chapter_2.book.provider" 
android: permission="com.ryg.PROVIDER" 
android: process=":provider" > 


</provider> 


注册 了 ContentProvider 以 后 ， 我 们 就 可 以 在 外 部 应 用 中 访问 它 了 。 
为 了 方便 演示 ， 这 里 仍然 选择 在 同一 个 应 用 的 其 他 进程 中 去 访问 这 个 
BookProvider， 至 于 在 单独 的 应 用 中 去 访问 这 个 BookProvider， 和 同一 
个 应 用 中 访问 的 效果 是 一 样 的 ， 读 者 可 以 自行 试 一 下 (注意 要 声明 对 应 
权限 ) 。 





//ProviderActivity.java 
public class ProviderActivity extends Activity { 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_provider ); 
Uri uri = Uri.parse("content://com.ryg.chapter_2.boo 
getContentResolver().query(uri, null, null,null, null); 
getContentResolver().query(uri, null, null,null,null); 


getContentResolver().query(uri, null, null,null, null); 


在 上 面 的 代码 中 ， 我 们 通过 ContentResolver 对 象 的 query 方 法 去 查询 
BookProvider 中 的 数据 ， 其 
中 “content://com.ryg.chapter_2.book.provider” 了 唯一 标识 Y BookProvider, 
而 这 个 标识 正 是 我 们 前 面 为 BookProvider 的 android:authorities 属 性 所 指定 
的 值 。 我 们 运行 后 看 一 下 log。 从 下 面 log 可 以 看 出 ，BookProvider 中 的 
query 方 法 被 调用 了 三 次 ， 并 且 这 三 次 调用 不 在 同一 个 线程 中 。 可 以 看 
出 ， 它 们 运行 在 一 个 Binder 线 程 中 ， 前 面 提 人 到 update、insert 和 delete 方 法 
同样 也 运行 在 Binder 线 程 中 。 另 外 ，onCreate 运 行 在 main 线 程 中 ， 也 就 
是 UI 线 程 ， 所 以 我 们 不 能 在 onCreate 中 做 耗 时 操作 。 


D/BookProvider(2091): onCreate,current thread:main 
D/BookProvider (2091): query,current thread:Binder Thread #2 
D/BookProvider (2091): query,current thread:Binder Thread #1 
D/BookProvider (2091): query,current thread:Binder Thread #2 
D/MyApplication(2091): application start,process name:com.ryg 


2: provider 





到 这 里 ， 整 个 ContentProvider 的 流程 我 们 已 经 跑 通 了 ， 虽 然 
ContentProvider 中 没有 返回 任何 数据 。 接 下 来 ， 在 上 面 的 基础 上 ， 我 们 
继续 完善 BookProvider， 从 而 使 其 能 够 对 外 部 应 用 提供 数据 。 继 续 本 章 
提 到 的 那个 例子 ， 现 在 我 们 要 提供 一 个 BookProvider， 外 部 应 用 可 以 通 
过 BookProvider 来 访问 图 书信 息 ， 为 了 更 好 地 演示 ContentProvider 的 使 
用 ， 用 户 还 可 以 通过 BookProvider 访 问 到 用 户 信 息 。 为 了 完成 上 述 功 
能 ， 我 们 需要 一 个 数据 库 来 管理 图 书 和 用 户 信 息 ， 这 个 数据 库 不 难 实 
现 ， 代 码 如 下 : 








// DbOpenHelper. java 
public class DbOpenHelper extends SQLiteOpenHelper { 


private static final String DB_NAME = "book_provider.db" 
public static final String BOOK_TABLE_NAME = "book"; 
public static final String USER_TALBE_NAME = "user"; 
private static final int DB_VERSION = 1; 
// 图 书 和 用 户 信 息 表 
private String CREATE_BOOK_TABLE = "CREATE TABLE IF NOT 
+ BOOK_TABLE_NAME + "(_id INTEGER PRIMARY KEY," 
private String CREATE_USER_TABLE = "CREATE TABLE IF NOT 
+ USER_TALBE_NAME + "(_id INTEGER PRIMARY KEY," 
"sex INT)"; 
public DbOpenHelper(Context context) { 
super (context, DB_NAME, null, DB VERSION); 
} 
@Override 
public void onCreate(SQLiteDatabase db) { 
db.execSQL(CREATE_BOOK_TABLE) ; 
db.execSQL(CREATE_USER_TABLE) ; 
J 
@Override 
public void onUpgrade(SQLiteDatabase db,int oldVersion,i 


// TODO ignored 


上 述 代 码 是 一 个 最 简单 的 数据 库 的 实现 ， 我 们 借助 
SQLiteOpenHelper 来 管理 数据 库 的 创建 、 升 级 和 降级 。 下 面 我 们 就 要 通 
过 BookProvider 辐 外 界 提供 上 述 数 据 库 中 的 信息 了 。 我 们 知道 ， 








ContentProvider 通 过 Uri 来 区 分 外 界 要 访问 的 的 数据 集合 ， 在 本 例 中 文 持 
外 界 对 BookProvider 中 的 book 表 和 user 表 进行 访问 ， 为 了 知道 外 界 要 访 
问 的 是 哪个 表 ， 我 们 需要 为 它们 定义 单独 的 Uri 和 Uri_Code， 并 将 Uri 和 
对 应 的 Uri_Code 相 关联 ， 我 们 可 以 使 用 UriMatcher 的 addURI 方 法 将 Uri 和 
Uri Code 关联 到 一 起 。 这 样 ， 当 外 界 请 求 访问 BookProvider 时 ， 我 们 了 束 
可 以 根据 请 求 的 Uri 来 得 到 Uri Code， 有 了 Uri Code 我 们 就 可 以 知道 外 
界 想 要 访问 哪个 表 ， 然 后 就 可 以 进行 相应 的 数据 操作 了 ， 有 具体 代码 如 下 
所 示 。 


public class BookProvider extends ContentProvider { 
private static final String TAG = "BookProvider"; 
public static final String AUTHORITY = "com.ryg.chapter_ 
provider"; 
public static final Uri BOOK_CONTENT_URI = Uri.parse("co 
+ AUTHORITY + "/book"); 
public static final Uri USER_CONTENT_URI = Uri.parse("co 
+ AUTHORITY + "/user"); 


public static final int BOOK_URI_CODE 


0; 
public static final int USER_URI_CODE 


1; 
private static final UriMatcher sUriMatcher = new UriMat 
UriMatcher .NO_MATCH); 
static { 
sUriMatcher .addURI (AUTHORITY, "book",BOOK_URI_CODE); 
sUriMatcher .addURI (AUTHORITY, "user", USER_URI_CODE) ; 


从 上 面 代码 可 以 看 出 ， 我 们 分 别 为 book 表 和 user 表 指定 了 Uri， 分 别 
73“content://com.ryg.chapter_2.book.provider/book” fll “content://com.ryg.ch 
provideruser”， 这 两 个 Uri 所 关联 的 Uri Code 分别 为 0 和 1。 这 个 关联 过 程 
是 通过 下 面 的 语句 来 完成 的 : 


sUriMatcher .addURI (AUTHORITY, "book", BOOK_URI_CODE); 
sUriMatcher .addURI (AUTHORITY, "user", USER URI CODE); 


将 Uri 和 Uri Code 管理 以 后 ， 我 们 就 可 以 通过 如 下 方式 来 获取 外 界 
所 要 访问 的 数据 源 ， 根 据 Uri 先 取出 Uri_ Code， 根据 Uri Code 再 得 到 数 
据 表 的 名 称 ， 知 道 了 外 界 要 访问 的 表 ， 接 下 来 就 可 以 啊 应 外 界 的 增删 改 
Bik S 











private String getTableName(Uri uri) { 

String tableName = null; 

switch (sUriMatcher.match(uri)) { 

case BOOK_URI_CODE: 
tableName = DbOpenHelper .BOOK_TABLE_NAME; 
break; 

case USER_URI_CODE: 
tableName = DbOpenHelper .USER_TALBE_NAME; 
break; 
default :break; 

Í 


return tableName; 


接着 ， 我 们 就 可 以 实现 query、update、insert、delete 方 法 了 。 如 下 





是 query 方 法 的 实现 ， 首 先 我 们 要 从 Uri 中 取出 外 界 要 访问 的 表 的 名 称 ， 
然后 根据 外 界 传 递 的 查询 参数 束 可 以 进行 数据 库 的 查询 操作 了 ， 这 个 过 
程 比较 简单 。 


@Override 
public Cursor query(Uri uri,String[] projection,String select 
String[] selectionArgs,String sortOrder) { 
Log.d(TAG, "query, current thread:" + Thread.currentThread( 
String table = getTableName(uri); 
if (table == null) { 
throw new IllegalArgumentException("Unsupported U 


} 


return mDb.query(table, projection, selection, selectionArgs 


另外 三 个 方法 的 实现 思想 和 query 是 类 似 的 ， 只 有 一 点 不 同 ， 那 就 
是 update、insert 和 delete 方 法 会 引起 数据 源 的 改变 ， 这 个 时 候 我 们 需要 
通过 ContentResolver 的 notifyChange 方 法 来 通知 外 界 当前 ContentProvider 
中 的 数据 已 经 发 生 改变 。 要 观察 一 个 ContentProvider 中 的 数据 改变 情 
况 ， 可 以 通过 ContentResolver 的 registerContentObserver 方 法 来 注册 观察 
者 ， 通 过 unregisterContentObserver 方 法 来 解除 观察 者 。 对 于 这 三 个 方 
法 ， 这 里 不 再 详细 解释 了 ，BookProvider 的 完整 代码 如 下 : 








public class BookProvider extends ContentProvider { 
private static final String TAG = "BookProvider"; 
public static final String AUTHORITY = "com.ryg.chapter_ 


public static final Uri BOOK_CONTENT_URI = Uri.parse("co 
+ AUTHORITY + "/book"); 


public static final Uri USER_CONTENT_URI = Uri.parse("co 
+ AUTHORITY + "/user"); 
public static final int BOOK_URI_CODE 


0; 
public static final int USER_URI_CODE 


1; 
private static final UriMatcher sUriMatcher = new UriMat 
UriMatcher .NO_MATCH); 
static { 
sUriMatcher .addURI(AUTHORITY, "book", BOOK_URI_CODE); 
sUriMatcher .addURI (AUTHORITY, "user", USER_URI_CODE); 
I 
private Context mContext; 
private SQLiteDatabase mDb; 
@Override 
public boolean onCreate() { 
Log.d(TAG, "onCreate, current thread:" 
+ Thread.currentThread().getName()); 
mContext = getContext(); 
//ContentProvider 创 建 时 ， 初 始 化 数据 库 。 注 意 : 这 里 仅仅 是 为 了 演示 ， 实 际 人 


initProviderData(); 





return true; 

} 

private void initProviderData() { 
mDb = new DbOpenHelper(mContext).getwritableDatabase 
mDb.execSQL("delete from " + DbOpenHelper .BOOK_TABLE 
mDb.execSQL("delete from " + DbOpenHelper .USER_TALBE 
mDb.execSQL("insert into book values(3, 'Android');") 


mDb.execSQL("insert into book values(4, 'Ios');"); 








if (row > 0) { 
getContext().getContentResolver().notifyChange(u 
} 
return row; 
} 
private String getTableName(Uri uri) { 
String tableName = null; 
switch (sUriMatcher.match(uri)) { 
case BOOK_URI_CODE: 
tableName = DbOpenHelper .BOOK_TABLE_NAME; 
break; 
case USER_URI_CODE: 
tableName = DbOpenHelper .USER_TALBE_NAME; 
break; 
default: break; 
J 


return tableName; 


} 





需要 注意 的 是 ，query、update、insert、delete 四 大 方法 是 存在 多 线 
程 并 发 访问 的 ， 因 此 方法 内 部 要 做 好 线程 同步 。 在 本 例 中 ， 由 于 采用 的 
是 SQLite 并 且 只 有 一 个 SQLiteDatabase 的 连接 ， 所 以 可 以 正确 应 对 多 线 
程 的 情况 。 具 体 原因 是 SQLiteDatabase 内 部 对 数据 库 的 操作 是 有 同步 处 
理 的 ， 但 是 如 果 通 过 多 个 SQLiteDatabase 对 象 来 操作 数据 库 就 无 法 保证 
线程 同步 ， 因 为 SQLiteDatabase 对 象 之 间 无 法 进行 线程 同步 。 如 果 
ContentProvider 的 底层 数据 集 是 一 块 内 存 的 话 ， 比 如 是 List， 在 这 种 情况 
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并 发 错误 ， 这 点 是 尤其 需要 注意 的 。 到 这 里 BookProvider 已 经 实现 完成 
了 ， 接 着 我 们 在 外 部 访问 一 下 它 ， 看 看 是 否 能 够 正常 工作 。 





public class ProviderActivity extends Activity { 
private static final String TAG = "ProviderActivity"; 
@Override 
protected void onCreate(Bundle savedInstanceState) { 


super .onCreate(savediInstanceState) ; 


Uri bookUri = Uri.parse("content://com.ryg.chapter_2 
book"); 
ContentValues values = new ContentValues(); 
values.put("_id",6); 
values.put("name", "程序 设计 的 艺术 " ) ; 
getContentResolver().insert(bookUri, values); 
Cursor bookCursor = getContentResolver().query(bookU 
{"_id", "name"},nul1l,null,null); 
while (bookCursor.moveToNext()) { 
Book book = new Book(); 
book.bookId = bookCursor.getInt(0); 
book.bookName = bookCursor.getString(1); 
Log.d(TAG, "query book:" + book.toString()); 
} 
bookCursor.close(); 
Uri userUri = Uri.parse("content://com.ryg.chapter_2 


user"); 


Cursor userCursor 


= getContentResolver().query(userU 


{"_id", "name", "sex"},null, null, null); 


while (userCursor 

User user = 
user .userId = 
user .userName 


user.isMale = 


.moveToNext()) { 


new User(); 


userCursor.getiInt(0); 
= userCursor.getString(1); 


userCursor.getiInt(2) == 1; 


Log.d(TAG, "query user:" + user.toString()); 


} 


userCursor.close(); 





默认 情况 下 ，BookProvider 的 数据 库 中 有 三 本 书 和 两 个 用 户 ， 在 上 
面 的 代码 中 ， 我 们 首先 添加 一 本 书 :“ 程 序 设计 的 艺术 ”。 接 看 但 询 所 有 
的 图 书 ， 这 个 时 候 应 该 但 询 出 四 本 书 ， 因 为 我 们 刚刚 添加 了 一 本 。 然 后 
查询 所 有 的 用 户 ， 这 个 时 候 应 该 查询 出 两 个 用 户 。 是 不 是 这 样 呢 ? 我 们 











运行 一 下 程序 ， 看 一 下 log。 








D/BookProvider( 1127): insert 


D/BookProvider( 1127): query,current thread:Binder Thread #1 


D/ProviderActivity( 1114): 
D/ProviderActivity( 1114): 
D/ProviderActivity( 1114): 


D/ProviderActivity( 1114): 


query book: [bookId:3,bookName:Andr 
query book: [bookId:4, bookName: Ios | 
query book: [bookId:5, bookName: Html 
query book: [bookId:6, bookName: f% + 


D/MyApplication( 1127): application start,process name:com.ry 


2: provider 


D/BookProvider( 1127): query,current thread:Binder Thread #3 
D/ProviderActivity( 1114): query user:User: {userId:1, userName 
isMale:true},with child: {null} 

D/ProviderActivity( 1114): query user:User: {userId:2, userName 


isMale:false},with child: {null} 


从 上 述 log 可 以 看 到 ， 我 们 的 确 查 询 到 了 4 本 书 和 2 个 用 户 ， 这 说 明 
BookProvider 己 经 能 够 正确 地 处 理 外 部 的 请 求 了 ， 读 者 可 以 自行 验证 一 
下 update 和 delete 操 作 ， 这 里 就 不 再 验证 了 。 同 时 ， 由 于 ProviderActivity 
和 BookProvider 运 行 在 两 个 不 同 的 进程 中 ， 因 此 ， 这 也 构成 了 进程 间 的 
通信 。ContentProvider 除 了 文 持 对 数据 源 的 增删 改 得 这 四 个 操作 ， 还 文 
持 目 定义 调用 ， 这 个 过 程 是 通过 ContentResolve 的 Call 方 法 和 
ContentProvider 的 Call 方 法 来 完成 的 。 关 于 使 用 ContentProvider 来 进行 
IPC 就 介绍 到 这 里 ，ContentProvider 本 身 还 有 一 些 细节 这 里 并 没有 介绍 ， 
读者 可 以 自行 了 解 ， 本 章 侧重 的 是 各 种 进程 间 通 信 的 方法 以 及 它们 的 区 
别 ， 因 此 针对 某 种 特定 的 方法 可 能 不 会 介绍 得 面面俱到 。 另 外 ， 
ContentProvider 在 后 续 章 市 还 会 有 进一步 的 讲解 ， 主 要 包括 细节 问题 和 
工作 原理 ， 读 者 可 以 阅读 后 面 的 相应 章 市 。 








2.4.6 {EH Socket 


在 本 节 中 ， 我 们 通过 Socket 来 实现 进程 间 的 通信 。Socket 也 称 为 “ 僚 
接 字 ”， 是 网 络 通 信 中 的 概念 ， 它 分 为 流 式 套 接 字 和 用 户 数据 报 套 接 字 
两 种 ， 分 别 对 应 于 网 络 的 传输 控制 层 中 的 TCP 和 UDP 协议 。TCP 协 议 是 
面 问 连接 的 协议 ， 提 供 稳定 的 双 同 通信 功能 ，TCP 连 接 的 建立 需要 经 
过 “三 次 握手 ”才能 完成 ， 为 了 提供 稳定 的 数据 传输 功能 ， 其 本 身 提供 了 








超时 重 传 机 制 ， 因 此 有 具有 很 高 的 稳定 性 ， 而 UDP 是 无 连接 的 ， 提 供 不 稳 
定 的 单 癌 通信 功能 ， 当 然 UDP 也 可 以 实现 双 同 通信 功能 。 在 性 能 上 ， 
UDP 具有 更 好 的 效率 ， 其 缺点 是 不 你 证 数据 一 定 能 够 正确 传输 ， 尤 其 是 
在 网 络 拥塞 的 情况 下 。 关 于 TCP 和 UDP 的 介绍 就 这 么 多 ， 更 详细 的 资料 
请 碍 看 相关 网 络 资料 。 接 下 来 我 们 演示 一 个 路 进程 的 聊天 程序 ， 两 个 进 
程 可 以 通过 Socket 来 实现 信息 的 传输 ，Socket 本 喘 可 以 文 持 传输 任意 字 
节 流 ， 这 里 为 了 简单 起 见 ， 仅 仅 传 输 文 本 信息 ， 很 显然 ， 这 是 一 种 IPC 
方式 。 

















使 用 Socket 来 进行 通信 ， 有 两 点 需要 注意 ， 首 先 需 要 声明 权限 : 


<uses-permission android:name="android.permission.INTERNET" / 


<uses-permission android:name="android.permission.ACCESS_NETW 


其 次 要 注意 不 能 在 主线 程 中 访问 网 络 ， 因 为 这 会 导致 我 们 的 程序 无 
法 在 Android 4.0 及 其 以 上 的 设备 中 运行 ， 会 抛 出 如 下 异常 : 
android.os.NetworkOnMainThreadException。 而 且 进 行 网 络 操作 很 可 能 是 
耗 时 的 ， 如 果 放 在 主线 程 中 会 影响 程序 的 啊 应 效率 ， 从 这 方面 来 说 ， 也 
不 应 该 在 主线 程 中 访问 网 络 。 下 面 就 开始 设计 我 们 的 聊天 室 程 序 了 ， 比 
较 简 单 ， 首 先 在 远程 Service 建 立 一 个 TCP 服 务 ， 然 后 在 主 界面 中 连接 
TCP 服 务 ， 连 接 上 了 以 后 ， 束 可 以 给 服务 端 发 消息 。 对 于 我 们 发 送 的 每 
一 条 文本 消息 ， 服 务 端 都 会 随机 地 回应 我 们 一 句 话 。 为 了 更 好 地 展示 
Socket 的 工作 机 制 ， 在 服务 问 我 们 做 了 处 理 ， 使 其 能 够 和 多 个 客户 端 同 
时 建立 连接 并 啊 应 。 














先 看 一 下 服务 端的 设计 ， 当 Service 局 动 时 ， 会 在 线程 中 建立 TCP 服 
务 ， 这 里 监听 的 是 8688 端 口 ， 然 后 就 可 以 等 待 客户 端的 连接 请 求 。 当 有 
客户 端 连接 时 ， 就 会 生成 一 个 新 的 Socket， 通 过 每 次 新 创建 的 Socket 就 


可 以 分 别 和 不 同 的 客户 端 通信 了 。 服 务 端 每 收 到 一 次 客户 端的 消息 就 会 
随机 回复 一 句 话 给 客户 端 。 当 客户 端 断 开 连接 时 ， 服 务 端 这 边 也 会 相应 
的 关闭 对 应 Socket 并 结束 通话 线程 ， 这 点 是 如 何 做 到 的 呢 ? 方法 有 很 
多 ， 这 里 是 通过 判断 服务 端 输入 流 的 返回 值 来 确定 的 ， 当 客户 端 断 开 连 
接 后 ， 服 务 端 这 边 的 输入 流 会 返回 null， 这 个 时 候 我 们 就 知道 客户 端 退 
出 了 。 服 务 端 的 代码 如 下 所 示 。 














接着 看 一 下 客户 端 ， 客 户 端 Activity 启 动 时 ， 会 在 onCreate 中 开启 一 
个 线程 去 连接 服务 端 Socket， 至 于 为 什么 用 线程 在 前 面 已 经 做 了 介绍 。 
为 了 确定 能 够 连接 成 功 ， 这 里 采用 了 超时 重 连 的 策略 ， 每 次 连接 失败 后 
都 会 重新 建立 尝试 建立 连接 。 当 然 为 了 降低 重 试 机 制 的 开销 ， 我 们 加 入 
了 休眠 机 制 ， 即 每 次 重 试 的 时 间 间 隔 为 1000 写 秒 。 











服务 端 连 接 成 功 以 后 ， 就 可 以 和 服务 端 进行 通信 了 。 下 面 的 代码 在 
线程 中 通过 while 循 环 不断 地 去 读 取 服 务 端 发 送 过 来 的 消息 ， 同 时 当 
Activity 退 出 时 ， 就 退出 循环 并 终止 线程 。 





同时 ， 当 Activity 退 出 时 ， 还 要 关闭 当前 的 Socket， 如 下 所 示 。 





接着 是 发 送 消息 的 过 程 ， 这 个 就 很 简单 了 ， 这 里 不 再 详细 说 明 。 客 
户 端的 完整 代码 如 下 : 














上 述 就 是 通过 Socket 来 进行 进程 间 通 信 的 实例 ， 除 了 采用 TCP 套 接 
字 ， 还 可 以 采用 UDP 套 接 字 。 另 外 ， 上 面 的 例子 仅仅 是 一 个 示例 ， 实 际 
上 通过 Socket 不 仅仅 能 实现 进程 间 的 通信 ， 还 可 以 实现 设备 间 的 通信 ， 
当然 前 提 是 这 些 设备 之 间 的 人 P 地 址 互相 可 见 ， 这 其 中 又 涉及 许多 复杂 的 
概念 ， 这 里 就 不 一 一 介绍 了 。 下 面 看 一 下 上 述 例 子 的 运行 效果 ， 如 图 2- 





9 所 示 。 


TCPClientActivity 





server (22:02:52): 欢 迎 来 到 聊天 室 ! 

self (22:03:08): {RF IH 

server (22:03:08): RiP ila , 哈哈 

self (22:03:25): (RMX RET ! 

server (22:03:25): 给 你 讲 个 笑话 吧 : 据说 爱 笑 的 人 运气 不 
会 太 差 ， 不 知道 真 假 。 


发 送 


图 2-9 Socket 通信 示例 


2.5 Binder 连接 池 


上 面 我 们 介绍 了 不 同 的 了 PC 方式 ， 我 们 知道 ， 不 同 的 IPC 方 式 有 不 同 
的 特点 和 适用 场景 ， 当 然 这 个 问题 会 在 2.6 节 进行 介绍 ， 在 本 节 中 要 再 
次 介绍 一 下 ADIL， 原 因 是 AIDL 是 一 种 最 常用 的 进程 间 通 信 方 式 ， 是 日 
常 开发 中 涉及 进程 间 通 信 时 的 首选 ， 所 以 我 们 需要 额外 强调 一 下 它 。 


如 何 使 用 AIDL 在 上 面 的 一 节 中 已 经 进行 了 介绍 ， 这 里 在 回顾 一 下 
大 致 流程 : 首先 创建 一 个 Service 和 一 个 AIDL 接 口 ， 接 着 创建 一 个 类 继 
承 自 AIDL 接 口中 的 Stub 类 并 实现 Stub 中 的 抽象 方法 ， 在 Service 的 onBind 
方法 中 返回 这 个 类 的 对 象 ， 然 后 客户 端 就 可 以 绑 定 服务 端 Service， 建 立 
连接 后 束 可 以 访问 远程 服务 端的 方法 了 。 


上 述 过 程 就 是 典型 的 AIDL 的 使 用 流程 。 这 本 来 也 没什么 问题 ， 但 
是 现在 考虑 一 种 情况 : 公司 的 项 目 越 来 越 庞 大 了 ， 现 在 有 10 个 不 同 的 业 
务 模 块 都 需要 使 用 AIDL 来 进行 进程 间 通 信 ， 那 我 们 该 怎么 处 理 呢 ?也 
许 你 会 说 :“ 就 按照 AIDL 的 实现 方式 一 个 个 来 吧 ”， 这 是 可 以 的 ， 如 果 
用 这 种 方法 ， 首 先 我 们 需要 创建 10 个 Service， 这 好 像 有 点 多 啊 ! 如 果 有 
100 个 地 方 需要 用 到 AIDL 呢 ， 先 创建 100 个 Service? 到 这 里 ， 读 者 应 该 
明白 问题 所 在 了 。 随 着 AIDL 数 量 的 增加 ， 我 们 不 能 无 限制 地 增加 
Service，Service 是 四 大 组 件 之 一 ， 本 里 就 是 一 种 系统 资源 。 而 且 太 多 的 
Service 会 使 得 我 们 的 应 用 看 起 来 很 重量 级 ， 因 为 正在 运行 的 Service 可 以 
在 应 用 详情 页 看 到 ， 当 我 们 的 应 用 详情 显示 有 10 个 服务 正在 运行 时 ， 这 
看 起 来 并 不 是 什么 好 事 。 针 对 上 述 问题 ， 我 们 需要 减少 Service 的 数量 ， 
将 所 有 的 AIDL 放 在 同一 个 Service 中 去 管理 。 





在 这 种 模式 下 ， 整 个 工作 机 制 是 这 样 的 : 每 个 业务 模块 创建 自己 的 
AIDL 接 口 并 实现 此 接口 ， 这 个 时 候 不 同业 务 模块 之 间 是 不 能 有 耦合 
的 ， 所 有 实现 细节 我 们 要 单独 开 来 ， 然 后 同 服 务 端 提供 自己 的 唯一 标识 
和 其 对 应 的 Binder 对 象 ， 对 于 服务 端 来 说 ， 只 需要 一 个 Service 束 可 以 
了 ， 服 务 端 提供 一 个 queryBinder 接 口 ， 这 个 接口 能 够 根据 业务 模块 的 特 
征 来 返回 相应 的 Binder 对 象 给 它们 ， 不 同 的 业务 模块 拿 到 所 需 的 Binder 
对 象 后 就 可 以 进行 远程 方法 调用 了 。 由 此 可 见 ，Binder 连 接 池 的 主要 作 
用 就 是 将 每 个 业务 模块 的 Binder 请 求 统 一 转发 到 远程 Service 中 去 执行 ， 
从 而 避免 了 重复 创建 Service 的 过 程 ， 它 的 工作 原理 如 图 2-10 所 示 。 
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图 2-10 Binder 连 接 池 的 工作 原理 


通过 上 面 的 理论 介绍 ， 也 许 还 有 点 不 好 理解 ， 下 面 对 Binder 连 接 池 
的 代码 实现 做 一 下 说 明 。 首 先 ， 为 了 说 明 问 题 ， 我 们 提供 了 两 个 AIDL 
接口 〈ISecurityCenter 和 ICompute) 来 模拟 上 面 提 到 的 多 个 业务 模块 都 
要 使 用 AIDL 的 情况 ， 其 中 ISecurityCenter 接 口 提供 加 解密 功能 ， 声 明 如 
下 : 


interface ISecurityCenter { 
String encrypt(String content); 
String decrypt(String password); 


而 ICompute 接 口 提供 计算 加 法 的 功能 ， 声 明 如 下 : 





虽然 说 上 面 两 个 接口 的 功能 都 比较 简单 ， 但 是 用 于 分 析 Binder 连 接 
池 的 工作 原理 已 经 足够 了 ， 读 者 可 以 写 出 更 复杂 的 例子 。 接 着 看 一 下 上 
面 两 个 AIDL 接 口 的 实现 ， 也 比较 简单 ， 代 码 如 下 : 








return a + b; 


} 


现在 业务 模块 的 AIDL 接 口 定义 和 实现 都 已 经 完成 了 ， 注 意 这 里 并 
没有 为 每 个 模块 的 AIDL 单 独创 建 Service， 接 下 来 就 是 服务 端 和 Binder 连 
接 池 的 工作 了 。 


首先 ， 为 Binder 连 接 池 创建 AIDL 接 口 IBinderPool.aidl， 代 码 如 下 所 


interface IBinderPool { 
pers 
* @param binderCode, the unique token of specific Binder 
* @return specific Binder who's token is binderCode. 
E 
IBinder queryBinder(int binderCode); 


} 


接着 ， 为 Binder 连 接 池 创建 远程 Service 并 实现 IBinderPool， 下 面 是 
queryBinder 的 具体 实现 ， 可 以 看 到 请 求 转发 的 实现 方法 ， 当 Binder 连 接 
池 连 接 上 远程 服务 时 ， 会 根据 不 同 模块 的 标识 即 binderCode 返 回 不 同 的 
Binder 对 象 ， 通 过 这 个 Binder 对 象 所 执行 的 操作 全 部 发 生 在 远程 服务 


` 


Uy o 


@Override 
public IBinder queryBinder(int binderCode) throws RemoteExcep 


IBinder binder = null; 


远程 Service 的 实现 就 比较 简单 了 ， 代 码 如 下 所 示 。 





return mBinderPool; 
} 
@Override 
public void onDestroy() { 


super.onDestroy()j; 








下 面 还 剩 下 Binder 连 接 池 的 具体 实现 ， 在 它 的 内 部 首先 它 要 去 绑 定 
远程 服务 ， 绑 定 成 功 后 ， 客 户 端 就 可 以 通过 它 的 queryBinder 方 法 去 获取 
各 自 对 应 的 Binder， 拿 到 所 需 的 Binder 以 后 ， 不 同业 务 模块 就 可 以 进行 
各 自 的 操作 了 ，Binder 连 接 池 的 代码 如 下 所 示 。 


public class BinderPool { 
private static final String TAG = "BinderPool"; 
public static final int BINDER_NONE = -1; 
public static final int BINDER_COMPUTE = 0; 
public static final int BINDER_SECURITY_CENTER = 1; 
private Context mContext; 
private IBinderPool mBinderPool; 
private static volatile BinderPool sInstance; 
private CountDownLatch mConnectBinderPoolCountDownLatch; 
private BinderPool(Context context) { 
mContext = context.getApplicationContext(); 
connectBinderPoolService()j; 


} 


public static BinderPool getInsance(Context context) { 











Binder 连 接 池 的 具体 实现 就 分 析 完 了 ， 它 的 好 处 是 显然 易 见 的 ， 针 
对 上 面 的 例子 ， 我 们 只 需要 创建 一 个 Service 即 可 完成 多 个 AIDL 接 口 的 
工作 ， 下 面 我 们 来 验证 一 下 效果 。 新 创建 一 个 Activity， 在 线程 中 执行 


如 下 操作 : 





try { 
String password = mSecurityCenter.encrypt(msg); 
System.out.println("encrypt:" + password); 
System.out.println("decrypt:" + mSecurityCenter.decr 
} catch (RemoteException e) { 
e.printStackTrace(); 
J 
Log.d(TAG, "visit ICompute"); 
IBinder computeBinder = binderPool 
.queryBinder (BinderPool.BINDER_COMPUTE); 
mCompute = ComputeImpl.asInterface(computeBinder); 
try { 
System.out.printin("3+5=" + mCompute.add(3,5)); 
} catch (RemoteException e) { 


e.printStackTrace(); 


在 上 述 代 码 中 ， 我 们 先后 调用 了 ISecurityCenter 和 ICompute 这 两 个 
AIDL 接 口中 的 方法 ， 看 一 下 log， 很 显然 ， 工 作 正 常 。 


D/BinderPoolActivity(20270): visit ISecurityCenter 
I/System.out(20270): content :helloworld-# 
I/System.out(20270): encrypt:6;221)1,2:s#ffj 





I/System.out(20270): decrypt :helloworld-# 5 
D/BinderPoolActivity(20270): visit ICompute 


I/System.out(20270): 3+5=8 


这 里 需要 额外 说 明 一 下 ， 为 什么 要 在 线程 中 去 执行 呢 ? 这 是 因为 在 
Binder 连 接 池 的 实现 中 ， 我 们 通过 CountDownLatch 将 bindService 这 一 异 
步 操 作 转 换 成 了 同步 操作 ， 这 就 意味 着 它 有 可 能 是 耗 时 的 ， 然 后 就 是 
Binder 方 法 的 调用 过 程 也 可 能 是 耗 时 的 ， 因 此 不 建议 放 在 主线 程 去 执 
行 。 注 意 到 BinderPool 是 一 个 单 例 实现 ， 因 此 在 同一 个 进程 中 只 会 初始 
化 一 次 ， 所 以 如 果 我 们 提前 初始 化 BinderPool， 那 么 可 以 优化 程序 的 体 
验 ， 比 如 我 们 可 以 放 在 Application 中 提前 对 BinderPool 进 行 初始 化 ， 虽 
然 这 不 能 保证 当 我 们 调用 BinderPool 时 它 一 定 是 初始 化 好 的 ， 但 是 在 大 
多 数 情 况 下 ， 这 种 初始 化 工作 《〈 绑 定 远程 服务 ) 的 时 间 开 销 《 如 果 
BinderPool 没 有 提前 初始 化 完成 的 话 ) 是 可 以 接受 的 。 另 外 ，BinderPool 
中 有 上 断 线 重 连 的 机 制 ， 当 远程 服务 意外 终止 时 ，BinderPool 会 重新 建立 
连接 ， 这 个 时 候 如 果 业 务 模块 中 的 Binder 调 用 出 现 了 异常 ， 也 需要 手动 
去 重新 获取 最 新 的 Binder 对 象 ， 这 个 是 需要 注意 的 。 








有 了 BinderPool 可 以 大 大 方便 日 常 的 开发 工作 ， 比 如 如 果 有 一 个 新 
的 业务 模块 需要 添加 新 的 AIDL， 那 么 在 它 实现 了 自己 的 AIDL 接 口 后 ， 
只 需要 修改 BinderPoolImpl 中 的 queryBinder 方 法 ， 给 自己 添加 一 个 新 的 
binderCode 并 返回 对 应 的 Binder 对 象 即 可 ， 不 需要 做 其 他 修改 ， 也 不 需 
要 创建 新 的 Service。 由 此 可 见 ，BinderPool 能 够 极 大 地 提高 AIDL 的 开发 
效率 ， 并 且 可 以 避免 大 量 的 Service 创 建 ， 因 此 ， 建 议 在 AIDL 开 发 工作 
中 引入 BinderPool 机 制 | 。 


2.6 ”选用 合适 的 IPC 方 式 


在 上 面 的 一 节 中 ， 我 们 介绍 了 各 种 各 样 的 IPC 方 式 ， 那 么 到 底 它们 
有 什么 不 同 呢 ? 我 们 到 底 该 使 用 哪 一 种 昵 ? 本 节 就 为 读者 解答 这 些 问 
题 ， 有 具体 内 容 如 表 2-2 所 示 。 通 过 表 2-2， 可 以 明确 地 看 出 不 同 IPC 方 式 


的 优 缺 点 和 适用 场景 ， 那 么 在 实际 的 开发 中 ， 


方式 束 可 以 轻松 完成 多 进程 的 开 肥 场景 。 


Bundle 


R2-2 


简单 易 用 


只 能 传输 Bundle 支持 的 数据 
类 型 





只 要 我 们 选择 合适 的 IPC 


1PC 方 式 的 优 缺 点 和 适用 场景 


四 大 组 件 问 的 进程 间 通 信 





文件 共享 


简单 易 用 


不 适合 高 并 发 场景 ， 并 且 无 
法 做 到 进程 间 的 即时 通信 


无 并 发 访问 情形 ,交换 简单 的 
数据 实时 性 不 高 的 场景 





AIDL 


功能 强大 ， 支 持 
信 ， 支 持 实时 通信 


-对 多 并 发 通 


使 用 稍 复杂 ， 需 要 处 理 好 线 


程 同 步 


-对 多 通信 且 有 RPC 需求 





Messenger 


功能 一 般 ， 支 持 一 对 多 串 行 通 
信 ， 支 持 实 时 通信 


不 能 很 好 处 理 高 并 发 情形 , 不 
支持 RPC, 数据 通过 Message 进 
行 传输 ， 因 此 只 能 传输 Bundle 
支持 的 数据 类 型 


低 并 发 的 一 对 多 即时 通信 ,无 
RPC 需求 ， 或 者 无 须要 返回 结 
果 的 RPC 需求 





ContentProvider 


在 数据 源 访问 方面 功能 强大 , 支 


持 一 对 多 并 发 数据 共享 ， 
Call 方 法 扩展 其 他 操作 


可 通过 


可 以 理解 为 受 约束 的 AIDL， 
主要 提供 数据 源 的 CRUD 操作 


-对 多 的 进程 间 的 数据 共享 





Socket 





功能 强大 , 可 以 通过 网 络 传输 字 


季 流 ， 支 持 一 对 多 并 发 实时 通信 


实现 细节 稍微 有 点 烦琐 ， 不 
支持 直接 的 RPC 








网 络 数据 交换 


第 3 曹 View 的 事件 体系 


本 章 将 介绍 Android 中 十 分 重要 的 一 个 概念 : View， 虽 然 说 View 不 
属于 四 大 组 件 ， 但 是 它 的 作用 堪 比 四 大 组 件 ， 甚 至 比 Receiver 和 Provider 
的 重要 性 都 要 大 。 在 Android 开 发 中 ，Activity 承 担 这 可 视 化 的 功能 ， 同 
时 Android 系 统 提供 了 很 多 基础 控件 ， 常 见 的 有 Button、TextView、 
CheckBox 等 。 很 多 时 候 仅 仅 使 用 系统 提供 的 控件 是 不 能 满足 需求 的 ， 
因此 我 们 就 需要 能 够 根据 需求 进行 新 控件 的 定义 ， 而 控件 的 自 定 义 束 需 
要 对 Android 的 View 体 系 有 深入 的 理解 ， 只 有 这 样 才能 写 出 完美 的 自 定 
义 控件 。 同 时 Android 手 机 属于 移动 设备 ， 移 动 设备 的 一 个 特点 就 是 用 
户 可 以 直接 通过 屏幕 来 进行 一 系列 操作 ， 一 个 典型 的 场景 承 是 屏幕 的 滑 
动 ， 用 户 可 以 通过 滑动 来 切换 到 不 同 的 界面 。 很 多 情况 下 我 们 的 应 用 都 
需要 文 持 滑动 操作 ， 当 处 于 不 同 层级 的 View 都 可 以 啊 应 用 户 的 请 动 操 作 
IN, BLAST ae, ASBESTOS. TUTE ARR SE ee? 这 对 
FOR NE PSI A Te a, SAR THR ASN ME, EE 
BE MY ViewH) St 4 a} AHL AE SRR, FEI PSEA, RATE A 
利于 这 个 特性 从 而 得 出 滑动 冲突 的 解决 方法 。 上 述 这 些 内 容 就 是 本 章 所 
要 介绍 的 内 容 ， 同 时 ，View 的 内 部 工作 原理 和 上 自 定义 View 相 关 的 知识 
会 在 第 4 章 进 行 介 绍 。 























3.1 View 基础 知识 





本 节 主 要 介绍 View 的 一 些 基础 知识 ， 从 而 为 更 好 地 介绍 后 续 的 内 容 


TouchSlop 对 象 、VelocityTracker、GestureDetector 和 Scroller 对 象 ， 通 过 
对 这 些 基础 知识 的 介绍 ， 可 以 方便 读者 理解 更 复杂 的 内 容 。 类 似 的 基础 
概念 还 有 不 少 ， 但 是 本 节 所 介绍 的 都 是 一 些 比较 第 用 的 ， 其 他 不 利用 的 
基础 概念 读者 可 以 自行 了 解 。 


3.1.1 什么 是 View 


在 介绍 View 的 基础 知识 之 前 ， 我 们 首先 要 知道 到 底 什么 是 View。 
View 是 Android 中 所 有 控件 的 基 类 ， 不 管 是 简单 的 Button 和 TextView 还 
是 复杂 的 RelativeLayout 和 ListView， 它 们 的 共同 基 类 都 是 View。 所 以 
说 ，View 是 一 种 界面 层 的 控件 的 一 种 抽象 ， 它 代表 了 一 个 控件 。 除 了 
View， 还 有 ViewGroup， 从 名 字 来 看 ， 它 可 以 被 翻译 为 控件 组 ， 言 外 之 
意 是 ViewGroup 内 部 包含 了 许多 个 控件 ， 即 一 组 View。 在 Android 的 设 
计 中 ，ViewGroup 也 继承 了 View， 这 惑 意 味 着 View 本 吴 承 可 以 是 单个 控 
件 也 可 以 是 由 多 个 控件 组 成 的 一 组 控件 ， 通 过 这 种 关系 吏 形 成 了 View 树 
的 结构 ， 这 和 Web 前 端 中 的 DOM 树 的 概念 是 相似 的 。 根 据 这 个 概念 ， 
我 们 知道 ，Button 显 然 是 个 View， 而 LinearLayout 不 但 是 一 个 View 而 且 
还 是 一 个 ViewGroup， 而 ViewGroup 内 部 是 可 以 有 子 View 的 ， 这 个 子 
View 同 样 还 可 以 是 ViewGroup， 依 此 类 推 。 





明白 View 的 这 种 层级 天 系 有 助 于 理解 View 的 工作 机 制 。 如 图 3-1 所 


示 ， 可 以 看 到 自 定义 的 TestButton 是 一 个 View， 它 继承 了 TextView， 而 
TextView 则 直接 继承 了 View， 因 此 不 管 怎么 说 ，TestButton 都 是 一 个 
View， 同 理 我 们 也 可 以 构造 出 一 个 继承 自 ViewGroup 的 控件 。 


Type hierarchy of ‘com.ryg.chapter_3.ui.TestButton’: 
a C) Object jā atang 


a@ View i e 
4 © TextView - android 





KƏ TestButton - com.ryg. EE 3.ui 


图 3-1 TestButton 的 层次 结构 


3.1.2 View 的 位 置 参 数 


View 的 位 置 主要 由 它 的 四 个 顶点 来 决定 ， 分 别 对 应 于 View 的 四 个 
属性 : top, left. right. bottom, H topt EAA Ab hn, left% Efi 
横 坐 标 ，right 是 右 下 角 横 坐标 ，bottom 是 右 下 角 纵 坐标 。 需 要 注意 的 
是 ， 这 些 坐 标 都 是 相对 于 View 的 父 容器 来 说 的 ， 因 此 它 是 一 种 相对 坐 
标 ，View 的 坐标 和 父 容器 的 关系 如 图 3-2 所 示 。 在 Android 中 ，x 轴 和 y 轴 
的 正方 向 分 别 为 右 和 下 ， 这 点 不 难 理解 ， 不 仅仅 是 Android， 大 部 分 显 
示 系 统 都 是 按照 这 个 标准 来 定义 坐标 系 的 。 








bottom 


ight ————> 


ViewGroup 





图 3-2 ”View 的 位 置 坐标 和 父 容器 的 关系 
根据 图 3-2， 我 们 很 容易 得 出 View 的 宽 高 和 坐标 的 关系 : 


width = right - left 
height = bottom - top 


那么 如 何 得 到 View 的 这 四 个 参数 呢 ? 也 很 简单 ， 在 View 的 源码 中 
它们 对 应 于 mLeft、mRight、mTop 和 mBottom 这 四 个 成 员 变 量 ， 获 取 方 
式 如 下 所 示 。 





e Left=getLeft(); 
e Right=getRight(); 


e Top=getTop; 
e Bottom=getBottom(). 


从 Android3.0 开 始 ，View 增 加 了 额外 的 几 个 参数 : x. ys 
translationX 和 translationY， 其 中 x 和 y 是 View 左 上 角 的 坐标 ， 而 
translationX 和 translationY 是 View 左 上 角 相 对 于 父 容器 的 偏 移 量 。 这 几 个 
参数 也 是 相对 于 父 容器 的 坐标 ， 并 且 translationX 和 translationY 的 默认 值 
是 0， 和 View 的 四 个 基本 的 位 置 参数 一 样 ，View 也 为 它们 提供 了 getset 
方法 ， 这 几 个 参数 的 换算 关系 如 下 所 示 。 


x=left+translationX 
y=top+translationY 


需要 注意 的 是 ，View 在 平移 的 过 程 中 ，top 和 ]left 表 示 的 是 原始 左上 
角 的 位 置信 息 ， 其 值 并 不 会 发 生 改 变 ， 此 时 发 生 改 变 的 是 x、y、 
translationX fll translation Y ix VY FER. 


3.1.3 MotionEvent#!TouchSlop 


1. MotionEvent 


在 手指 接触 屏幕 后 所 产生 的 一 系列 事件 中 ， 典 型 的 事件 类 型 有 如 下 
几 种 : 


e ACTION_DOWN- 手指 刚 接触 屏幕 ; 
e ACTION_MOVE 一 手指 在 屏幕 上 移动 ; 
e ACTION_UP- 一 手机 从 屏幕 上 松 开 的 一 瞬间 。 
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碟 如 下 几 种 情况 : 


。 点 击 屏 幕后 离开 松 开 ， 事 件 序列 为 DOWN -> UP; 
。 点 击 屏 幕 滑 动 一 会 再 松 开 ， 事 件 序列 为 DOWN -> MOVE -> ... > 
MOVE -> UP。 


上 述 三 种 情况 是 典型 的 事件 序列 ， 同 时 通过 MotionEvent 对 象 我 们 
可 以 得 到 点 击 事件 发 生 的 x 和 y 坐 标 。 为 此 ， 系 统 提供 了 两 组 方法 : 
getX/getY 和 getRawX/getRawY。 它 们 的 区 列 其 实 很 简单 ，getX/getY 返 回 
的 是 相对 于 当前 View 左 上 角 的 x 和 y 坐 标 ， 而 getRawX/getRawY 返 回 的 是 
相对 于 手机 屏幕 左上 角 的 x 和 y 坐 标 。 


2. TouchSlop 


TouchSlop 是 系统 所 能 识别 出 的 被 认为 是 滑动 的 最 小 距离 ， 换 人 句 话 
说 ， 当 手指 在 屏幕 上 滑动 时 ， 如 采 两 次 滑动 之 间 的 距离 小 于 这 个 第 量 ， 
IBZ BAIA WA VR TERE TIA SUERTE. JAR fa: 滑动 的 距离 太 
短 ， 系 统 不 认为 它 是 滑动 。 这 是 一 个 常量 ， 和 设备 有 关 ， 在 不 同 设备 上 
这 个 值 可 能 是 不 同 的 ， 通 过 如 下 方式 即 可 获取 这 个 常量 : 
ViewConfiguration. ”get(getContext()).getScaledTouchSlop()。 这 个 常量 有 
什么 意义 呢 ?” 当 我 们 在 处 理 滑动 时 ， 可 以 利用 这 个 常量 来 做 一 些 过 滤 ， 
比如 当 两 次 滑动 事件 的 滑动 距离 小 于 这 个 值 ， 我 们 就 可 以 认为 未 达到 背 
动 距离 的 临界 值 ， 因 此 就 可 以 认为 它们 不 是 滑动 ， 这 样 做 可 以 有 更 好 的 
用 户 体 验 。 其 实 如 果 细 心 的 话 ， 可 以 在 源码 中 找到 这 个 常量 的 定义 ， 在 
frameworks/base/core/res/res/values/config.xml 文 件 中 ， 如 下 所 示 。 这 
个 “config_viewConfigurationTouchSlop” 对 应 的 就 是 这 个 常量 的 定义 。 























<!--Base "touch slop" value used by ViewConfiguration as a mo 
where scrolling should begin. --> 


<dimen name="config_viewConfigurationTouchSlop">8dp</dimen> 


3.1.4 VelocityTracker,. 
GestureDetector fil Scroller 


1. VelocityTracker 








速度 退 踪 ， 用 于 妃 踪 手指 在 滑动 过 程 中 的 速度 ， 包 括 水 平和 竖 直 方 
癌 的 速度 。 它 的 使 用 过 程 很 简单 ， 首 先 ， 在 View 的 onTouchEvent 方 法 中 
奶 踪 当前 单 击 事件 的 速度 : 





VelocityTracker velocityTracker = VelocityTracker.obtain(); 


VelocityTracker .addMovement(event); 











接着 ， 当 我 们 先知 道 当 前 的 冲动 速度 时 ， 这 个 时 候 可 以 采用 如 下 方 
式 来 获得 当前 的 速度 : 


velocityTracker.computeCurrentVelocity(1000); 
int xVelocity = (int) velocityTracker.getXVelocity(); 


int yVelocity = (int) velocityTracker.getYVelocity(); 








在 这 一 步 中 有 两 点 需要 注意 ， 第 一 点 ， 获 取 速 度 之 前 必须 先 计 算 速 
度 ， 即 getXVelocity 和 getYVelocity 这 两 个 方法 的 前 面 必须 要 调用 
computeCurrentVelocity 方 法 ; 第 二 点 ， 这 里 的 速度 是 指 一 段 时 间 内 手指 
所 滑 过 的 像 际 数 ， 比 如 将 时 间 间 隔 设 为 1000ms 时 ， 在 1s 内 ， 手 指 在 水 平 
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数 ， 当 手指 从 右 往 左 滑动 时 ， 水 平方 癌 速 度 即 为 负 值 ， 这 个 需要 理解 一 
下 。 速 度 的 计算 可 以 用 如 下 公式 来 表示 : 








速度 =〈 终 点 位 置 -起 点 位 置 ) /时 间 段 


根据 上 面 的 公式 再 加 上 Android 系 统 的 坐标 系 ， 可 以 知道 ， 手 指 逆 
着 坐标 系 的 正方 向 滑动 ， 所 产生 的 速度 束 为 负 值 。 另 外 ， 
computeCurrentVelocity 这 个 方法 的 参数 表示 的 是 一 个 时 间 单 元 或 者 说 时 
AAR, EASED Cms) ， 计 算 速 上 度 时 得 到 的 速度 就 是 在 这 个 时 
间 间 隅 内 手指 在 水 乎 或 竖 直 方向 上 所 滑动 的 像素 数 。 针 对 上 面 的 例子 ， 
如 果 我 们 通过 velocityTracker.computeCurrentVelocity(100) 来 获取 速度 ， 
那么 得 到 的 速度 就 是 手指 在 100ms 内 所 滑 过 的 像素 数 ， 因 此 水 平 速 度 束 
成 了 10 像 素 / 每 100ms《〈《 这 里 假设 滑动 过 程 是 勺 速 的 ) ， 即 水 平 速度 为 
10， 这 点 需要 好 好 理解 一 下 。 








最 后 ， 当 不 需要 使 用 它 的 时 候 ， 需 要 调用 clear 方 法 来 重 置 并 回收 内 
fi: 


velocityTracker.clear(); 


velocityTracker.recycle(); 


上 面 就 是 如 何 使 用 VelocityTracker 对 象 的 全 过 程 ， 看 起 来 并 不 复 


se 


2. GestureDetector 


手势 检测 ， 用 于 辅助 检测 用 户 的 单 击 、 滑 动 、 长 按 、 双 击 等 行为 。 
要 使 用 GestureDetector 也 不 复杂 ， 参 考 如 下 过 程 。 


首先 ， 需 要 创建 一 个 GestureDetector 对 象 并 实现 OnGestureListener 接 
口 ， 根 据 需要 我 们 还 可 以 实现 OnDoubleTapListener 从 而 能 够 监听 双击 行 
为 : 

GestureDetector mGestureDetector = new GestureDetector(this) 

// 解 决 长 按 屏 幕后 无 法 拖 动 的 现象 


mGestureDetector.setIsLongpressEnabled(false); 


接着 ， 接 管 目 标 View 的 onTouchEvent 方 法 ， 在 待 监听 View 的 
onTouchEvent 方 法 中 添加 如 下 实现 : 


boolean consume = mGestureDetector.onTouchEvent(event); 


return consume; 


做 完了 上 面 两 步 ， 我 们 就 可 以 有 选择 地 实现 OnGestureListener 和 
OnDoubleTapListener 中 的 方法 了 ， 这 两 个 接口 中 的 方法 介绍 如 表 3-1 所 
ar 


#3-1 0nGestureListener 和 0nDoubleTapListener 中 的 方法 介绍 


所 属 接 口 
onDown 手指 轻 轻 触摸 屏幕 的 一 瞬间 ， 由 1 个 ACTION_DOWN 触发 OnGestureListener 
手指 轻 轻 触摸 屏幕 ， 尚 未 松 开 或 拖 动 ， 由 1 个 ACTION_DOWN 触发 


onShowPress Toe L NESA See ale a OnGestureListener 
* 注意 和 onDown() 的 区 别 ， 它 强调 的 是 没有 松 开 或 者 拖 动 的 状态 








手指 ( 轻 轻 触摸 屏幕 后 ) 松 开 ， 伴 随 着 1 个 MotionEventACTION UP | _ 
onSingleTapUp sed “Sit mecati OnGestureListener 
i 而 触发 ， 这 是 单 击 行为 


手指 按 下 屏幕 并 拖 动 ,由 1 个 ACTION_DOWN, 多 个 ACTION MOVE 


onScroll 3 kiteen OnGestureListener 
触发 ， 这 是 拖 动 行为 








onLongPress 用 户 长 久 地 按 着 屏幕 不 放 ， 即 长 按 OnGestureListener 
用 户 按 下 触摸 屏 、 快 速 滑动 后 松 开 ， 由 1 个 ACTION_DOWN、 多 个 


onFling 更 PETE OnGestureListener 
5 ACTION MOVE 和 1 个 ACTION UP 触发 ， 这 是 快速 滑动 行为 , ait 











双击 ， 由 2 次 连续 的 单 击 组 成 ， 它 不 可 能 和 onSingleTapConfirmed 共 
在 


onDoubleTap OnDoubleTapListener 





严格 的 单 击 行为 
. _ * 注 意 它 和 onSingleTapUp 的 区 别 , 如果 触发 了 onSingleTapConfirmed， 
onSingleTapConfirmed _ pda re Roh es Sec | OnDoubleTapListener 
那么 后 面 不 可 能 再 紧 跟 着 另 一 个 单 击 行为 ， 即 这 只 可 能 是 单 击 ， 而 不 可 
能 是 双击 中 的 一 次 单 击 
表示 发 生 了 双击 行为 ， 在 双击 的 期 间 ，ACTION_ DOWN Ô, 
ACTION MOVE 和 ACTION _UP 都 会 触发 此 回调 





onDoubleTapEvent OnDoubleTapListener 











表 3-1 里 面 的 方法 很 多 ， 但 是 并 不 是 所 有 的 方法 都 会 被 时 常用 到 ， 

在 日 常 开 发 中 ， 比 较 常 用 的 有 : onSingleTapUp (iH) ~ onFling OR 
速 滑动 ) 、onScroll ( 拖 动 ) 、onLongPress (长 按 ) #lonDoubleTap (XX 
击 ) 。 另 外 这 里 要 说 明 的 是 ， 实 际 开 发 中 ， 可 以 不 使 用 
GestureDetector， 完 全 可 以 自己 在 View 的 onTouchEvent 方 法 中 实现 所 需 
的 监听 ， 这 个 就 看 个 人 的 喜好 了 。 这 里 有 一 个 建议 供 读者 参考 :如果 只 
是 监听 滑动 相关 的 ， 建 议 目 己 在 onTouchEvent 中 实现 ， 如 果 要 监听 双击 
这 种 行为 的 话 ， 那 么 束 使 用 GestureDetector。 





3. Scroller 


弹性 滑动 对 象 ， 用 于 实现 View 的 弹性 滑动 。 我 们 知道 ， 当 使 用 
View 的 scrollTo/scrollBy 方 法 来 进行 滑动 时 ， 其 过 程 是 瞬间 完成 的 ， 这 个 
没有 过 渡 效 果 的 滑动 用 户 体验 不 好 。 这 个 时 候 就 可 以 使 用 Scroller 来 实现 
有 过 渡 效 果 的 请 动 ， 其 过 程 不 是 瞬间 完成 的 ， 而 是 在 一 定 的 时 间 间 隔 内 
完成 的 。Scroller 本 身 无 法 让 View 弹 性 滑动 ， 它 需要 和 View 的 





computeScroll 方 法 配合 使 用 才能 共同 完成 这 个 功能 。 那 么 如 何 使 用 
Scroller 呢 ?” 它 的 典型 代码 是 固定 的 ， 如 下 所 示 。 人 至 于 它 为 什么 能 实现 弹 
性 滑动 ， 这 个 在 3.2 节 中 会 进行 详细 介绍 。 





3.2 View 的 滑动 


3.1 节 介绍 了 View 的 一 些 基 础 知识 和 概念 ， 本 节 开 始 介绍 很 重要 的 
一 个 内 容 : View 的 滑动 。 在 Android 设 备 上 ， 滑 动 几乎 是 应 用 的 标 配 ， 
不 管 是 下 拉 刷 新 还 是 SlidingMenu， 它 们 的 基础 都 是 滑动 。 从 另外 一 方 
面 来 说 ，Android 手 机 由 于 屏幕 比较 小 ， 为 了 给 用 户 呈 现 更 多 的 内 容 ， 
就 需要 使 用 滑动 来 隐藏 和 显示 一 些 内 容 。 基 于 上 述 两 点 ， 可 以 知道 ， 滑 
动 在 Android 开 发 中 具有 很 重要 的 作用 ， 不 管 一 些 滑动 效果 多 么 绚丽 ， 
归根 结 底 ， 它 们 都 是 由 不 同 的 滑动 外 加 一 些 特效 所 组 成 的 。 因 此 ， 午 握 
滑动 的 方法 是 实现 绚丽 的 自 定义 控件 的 基础 。 通 过 三 种 方式 可 以 实现 
View 的 滑动 : 第 一 种 是 通过 View 本 和 里 提供 的 scrollTo/scrollBy 方 法 来 实 
现 滑 动 ， 第 二 种 是 通过 动画 给 View 施 加 平移 效果 来 实现 滑动 ， 第 三 种 是 
通过 改变 View 的 LayoutParams 使 得 View 重 新 布局 从 而 实现 滑动 。 从 目前 
来 看 ， 常 见 的 滑动 方式 就 这 么 三 种 ， 下 面 一 一 进行 分 析 。 




















3.2.1 ”使 用 scrollTo/scrollBy 





为 了 实现 View 的 滑动 ，View 提 供 了 专门 的 方法 来 实现 这 个 功能 ， 
那 就 是 scrollTo 和 scrollBy， 我 们 先 来 看 看 这 两 个 方法 的 实现 ， 如 下 所 
TR 





fie 
* Set the scrolled position of your view. This will cause a 
* {@link #onScrollChanged(int,int,int,int)} and the view wi 


* invalidated. 





从 上 面 的 源码 可 以 看 出 ，scrollBy 实 际 上 也 是 调用 了 scrollTo 方 法 ， 
它 实 现 了 基于 当前 位 置 的 相对 滑动 ， 而 scrollTo 则 实现 了 基于 所 传递 参 
数 的 绝对 滑动 ， 这 个 不 难 理解 。 利 用 scrollTo 和 scrollBy 来 实现 View 的 滑 
动 ， 这 不 是 一 件 困难 的 事 ， 但 是 我 们 要 明白 滑动 过 程 中 View 内 部 的 两 个 
属性 mScrollX 和 mScrollY 的 改变 规则 ， 这 两 个 属性 可 以 通过 getScrollX 和 
getScrollY 方 法 分 别 得 到 。 这 里 先 简 要 概况 一 下 : 在 滑动 过 程 中 ， 
msScrollX 的 值 总 是 等 于 View 左 边缘 和 View 内 容 左 边缘 在 水 平方 向 的 距 
离 ， 而 mScrollY 的 值 总 是 等 于 View 上 边缘 和 View 内 容 上 边缘 在 竖 直 方 
癌 的 距离 。View 边 缘 是 指 View 的 位 置 ， 由 四 个 顶点 组 成 ， 而 View 内 容 
边缘 是 指 View 中 的 内 容 的 边缘 ，scrollTo 和 scrollBy 只 能 改变 View 内 容 的 
位 置 而 不 能 改变 View 在 布局 中 的 位 置 。mScrollX 和 mScrollY 的 单位 为 像 
素 ， 并 且 当 View 左 边缘 在 View 内 容 左 边缘 的 右边 时 ，mScrolX 为 正 
值 ， 反 之 为 负 值 ;， 当 View 上 边缘 在 View 内 容 上 边缘 的 下 边 时 ， 
mScrolY 为 正 值 ， 反 之 为 负 值 。 换 名 话说 ， 如 果 从 左 回 右 滑动 ， 那 么 
mScrollX 为 负 值 ， 反 之 为 正 值 ， 如 果 从 上 往 下 滑动 ， 那 么 mScrollY 为 负 
值 ， 反 之 为 正 值 。 














为 了 更 好 地 理解 这 个 问题 ， 下 面 举 个 例子 ， 如 图 3-3 所 示 。 在 图 中 
假设 水 平和 竖 直 方 加 的 滑动 距离 都 为 100 像 素 ， 针 对 图 中 各 种 滑动 情 
况 ， 都 给 出 了 对 应 的 mScrolX 和 mScrolY 的 值 。 根 据 上 面 的 分 析 ， 可 以 
知道 ， 使 用 scrollTo 和 scrollBy 来 实现 View 的 滑动 ， 只 能 将 View 的 内 容 进 
行 移动 ， 并 不 能 将 View 本 号 进行 移动 ， 也 就 是 说 ， 不 管 怎么 滑动 ， 也 不 
可 能 将 当前 View 滑 动 到 附近 View 所 在 的 区 域 ， 这 个 需要 仔细 体会 一 
Te 








原始 状态 


mScrollX = 0 mScrollX = 100 mScrollX =-100 
mScrollY = 0 











mScrollX =-100 


mScrollY = 100 mScroll¥ = 100 mScrollY = -100 


图 3-3 mScrol1X 和 mScrol1Y 的 变换 规律 示意 


3.2.2 ”使 用 动画 


上 一 节 介 绍 了 采用 scrollTo/scrollBy 来 实现 View 的 滑动 ， 本 节 介 绍 另 
外 一 种 滑动 方式 ， 即 使 用 动画 ， 通 过 动画 我 们 能 够 让 一 个 View 进 行 平 
移 ， 而 平移 就 是 一 种 滑动 。 使 用 动画 来 移动 View， 主 要 是 操作 View 的 
translationX 和 translationY 属 性 ， 既 可 以 采用 传统 的 View 动 男 ， 也 可 以 采 
用 属性 动画 ， 如 有 果 采 用 属性 动画 的 话 ， 为 了 能 够 兼容 3.0 以 下 的 版 本 ， 
需要 采用 开源 动画 库 nineoldandroids (http://nineoldandroids.com/) 。 


采用 View 动 画 的 代码 ， 如 下 所 示 。 此 动画 可 以 在 100ms 内 将 一 个 
View 从 原始 位 置 同 右 下 角 移 动 100 个 像素 。 





<?xml version="1.0" encoding="utf-8"?> 


<set xmlns:android="http://schemas.android.com/apk/res/androi 


android: fillAfter="true" 
android: zAdjustment="normal" > 
<translate 
android: duration="100" 
android: fromxXDelta="0" 
android: fromYDelta="0" 
android: interpolator="@android:anim/linear_interpola 
android: toxXDelta="100" 
android: toYDelta="100" /> 


</set> 


如 果 采 用 属性 动画 的 话 ， 束 更 简单 了 ， 以 下 代码 可 以 将 一 个 View 在 
100ms 内 从 原始 位 置 向 右 平移 100 像 素 。 


ObjectAnimator.ofFloat(targetView, "translationxX",0,100).setDu 
(100).start(); 


上 面 简单 介绍 了 通过 动画 来 移动 View 的 方法 ， 关 于 动画 会 在 第 5 章 
中 进行 详细 说 明 。 使 用 动画 来 做 View 的 滑动 需要 注意 一 点 ，View 动 画 
是 对 View 的 影像 做 操作 ， 它 并 不 能 真正 改变 View 的 位 置 参数 ， 包 括 宽 / 
高 ， 并 且 如 果 和 希望 动画 后 的 状态 得 以 保留 还 必须 将 旨 After 属 性 设置 为 
true， 人 否则 动画 完成 后 其 动画 结果 会 消失 。 比 如 我 们 要 把 View 回 右 移 动 
100 像 素 ， 如 果 filAfter 为 false， 那 么 在 动画 完成 的 一 判 那 ，View 会 瞬间 
恢复 到 动画 前 的 状态 ， 如 果 fillAfter 为 tue， 在 动画 完成 后 ，View 会 停留 
在 距 原 始 位 置 100 像 素 的 右边 。 使 用 属性 动画 并 不 会 存在 上 述 问题 ， 但 
是 在 Android 3.0 以 下 无 法 使 用 属性 动画 ， 这 个 时 候 我 们 可 以 使 用 动画 兼 
容 库 nineoldandroids 来 实现 属性 动画 ， 尽 管 如 此 ， 在 Android 3.0 以 下 的 
手机 上 通过 nineoldandroids 来 实现 的 属性 动画 本 质 上 仍然 是 View 动 画 。 





























上 面 提 到 View 动 画 并 不 能 真正 改变 View 的 位 置 ， 这 会 带 来 一 个 很 
严重 的 问题 。 试 想 一 下 ， 比 如 我 们 通过 View 动 画 将 一 个 Button 同 右 移 动 
100px， 并 且 这 个 View 设 置 的 有 单 击 事件 ， 然 后 你 会 尺 奇 地 发 现 ， 单 击 
新 位 置 无 法 触发 onClick 事 件 ， 而 单 击 原始 位 置 仍然 可 以 触发 onClick 事 
件 ， 尽 管 Button 已 经 不 在 原始 位 置 了 。 这 个 问题 带 来 的 影响 是 致命 的 ， 
但 是 它 却 又 是 可 以 理解 的 ， 因 为 不 管 Button 怎 么 做 变换 ， 但 是 它 的 位 置 
言 上 号 《四 个 顶点 和 宽 / 高 〉 并 不 会 随 着 动画 而 改变 ， 因 此 在 系统 眼 里 ， 
这 个 Button 并 没有 发 生 任何 改变 ， 它 的 真 刁 仍然 在 原始 位 置 。 在 这 种 情 
况 下 ， 单 击 新 位 置 当 然 不 会 触发 onClick 事 件 了 ， 因 为 Button 的 真 身 并 没 
有 发 生 改变 ， 在 新 位 置 上 只 是 View 的 影像 而 已 。 基 于 这 一 点 ， 我 们 不 能 
简单 地 给 一 个 View 做 平移 动画 并 且 还 希望 它 在 新 位 置 继 续 触 发 一 些 单 击 
事件 。 





























从 Android 3.0 开 始 ， 使 用 属性 动画 可 以 解决 上 面 的 问题 ， 但 是 大 多 
数 应 用 都 需要 兼容 到 Android 2.2， 在 Android 2.2 上 无 法 使 用 属性 动画 ， 
因此 这 里 还 是 会 有 问题 。 那 么 这 种 问题 难道 束 无 法 解决 了 吗 ? 也 不 是 
的 ， 昌 然 不 能 直接 解决 这 个 问题 ， 但 是 还 可 以 间接 解决 这 个 问题 ， 这 里 
给 出 一 个 简单 的 解决 方法 。 针 对 上 面 View 动 画 的 问题 ， 我 们 可 以 在 新 位 
置 预 完 创建 一 个 和 目标 Button 一 模 一 样 的 Button， 它 们 不 但 外 观 一 样 连 
onClick 事 件 也 一 样 。 当 目标 Button 完 成 平移 动画 后 ， 就 把 目标 Button 隐 
藏 ， 同 时 把 预先 创建 的 Button 显 示 出 来 ， 通 过 这 种 间接 的 方式 我 们 解决 
了 上 面 的 问题 。 这 仅仅 是 个 参考 ， 面 对 这 种 问题 时 读者 可 以 灵活 应 对 。 


3.2.3 ”改变 布局 参数 


本 节 将 介绍 第 三 种 实现 View 滑 动 的 方法 ， 那 就 是 改变 布局 参数 ， 即 

















改变 LayoutParams。 这 个 比较 好 理解 了 ， 比 如 我 们 想 把 一 个 Button 回 右 
平移 100px， 我 们 只 需要 将 这 个 Button 的 LayoutParams 里 的 marginLeft 参 
数 的 值 增 加 100px 即 可 ， 是 不 是 很 简单 呢 ? 还 有 一 种 情形 ， 为 了 达到 移 
动 Button 的 目的 ， 我 们 可 以 在 Button 的 左边 放置 一 个 空 的 View， 这 个 空 
View 的 默认 宽度 为 0， 当 我 们 需要 癌 右 移动 Button 时 ， 只 需要 重新 设置 
空 View 的 宽度 即 可 ， 当 空 View 的 宽度 增 大 时 《假设 Button 的 父 容器 是 水 
平方 同 的 LinearLayout) ，Button 就 自动 被 挤 回 右边 ， 即 实现 了 回 右 平移 
的 效果 。 如 何 重 新 设置 一 个 View 的 LayoutParams 呢 ? 很 简单 ， 如 下 所 
示 。 








MarginLayoutParams params = (MarginLayoutParams)mButton1.getL 
params.width += 100; 

params.leftMargin += 100; 

mButton1.requestLayout(); 


//XAmButton1.setLayoutParams(params); 


通过 改变 LayoutParams 的 方式 去 实现 View 的 滑动 同样 是 一 种 很 灵活 
的 方法 ， 需 要 根据 不 同情 况 去 做 不 同 的 处 理 。 


3.2.4 各 种 滑动 方式 的 对 比 


上 面 分 别 介绍 了 三 种 不 同 的 滑动 方式 ， 它 们 都 能 实现 View 的 滑动 ， 
那么 它们 之 间 的 差别 是 什么 呢 ? 








先 看 scrollTo/scrollBy 这 种 方式 ， 它 是 View 提 供 的 原生 方法 ， 其 作用 
是 专门 用 于 View 的 滑动 ， 它 可 以 比较 方便 地 实现 滑动 效果 并 且 不 影响 内 
部 元 素 的 单 击 事件 。 但 是 它 的 缺点 也 是 很 显然 的 : 它 只 能 滑动 View 的 内 
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再 看 动画 ， 通 过 动画 来 实现 View 的 滑动 ， 这 要 分 情况 。 如 果 是 
Android 3.0 以 上 并 采用 属性 动画 ， 那 么 采用 这 种 方式 没有 明显 的 缺点 ; 
如 果 是 使 用 View 动 画 或 者 在 Android 3.0 以 下 使 用 属性 动画 ， 均 不 能 改变 
View 本 身 的 属性 。 在 实际 使 用 中 ， 如 果 动 画 元 素 不 需要 啊 应 用 户 的 交 
互 ， 那 么 使 用 动画 来 做 背 动 是 比较 合适 的 ， 否 则 就 不 太 适 合 。 但 是 动画 
有 一 个 很 明显 的 优点 ， 那 就 是 一 些 复杂 的 效果 必须 要 通过 动画 才能 实 
现 。 














最 后 再 看 一 下 改变 布局 这 种 方式 ， 它 除了 使 用 起 来 麻烦 点 以 外 ， 也 
没有 明显 的 缺点 ， 它 的 主要 适用 对 象 是 一 些 具 有 交互 性 的 View， 因 为 这 
些 View 需 要 和 用 户 交 互 ， 直 接 通过 动画 去 实现 会 有 问题 ， 这 在 3.2.2 节 中 
已 经 有 所 介绍 ， 所 以 这 个 时 候 我 们 可 以 使 用 直接 改变 布局 参数 的 方式 去 
实现 。 








针对 上 面 的 分 析 做 一 下 总 结 ， 如 下 所 示 。 


e scrollTo/scrollBy: 操作 人 简单， 适合 对 View 内 容 的 请 动 ; 

。 动画 : 操作 简单 ， 主 要 适用 于 没有 交互 的 View 和 实现 复杂 的 动画 效 
R; 

。 改变 布局 参数 :操作 稍微 复杂 ， 适 用 于 有 交互 的 View。 





下 面 我 们 实现 一 个 跟 手 滑动 的 效果 ， 这 是 一 个 自 定义 View， 拖 动 它 
可 以 让 它 在 整个 屏幕 上 随意 滑动 。 这 个 View 实 现 起 来 很 简单 ， 我 们 只 要 
重 写 它 的 onTouchEvent 方 法 并 处 理 ACTION_MOVE 事 件 ， 根 据 两 次 滑动 
之 间 的 距离 就 可 以 实现 它 的 请 动 了 。 为 了 实现 全 屏 滑动 ， 我 们 采用 动画 
的 方式 来 实现 。 原 因 很 简单 ， 这 个 效果 无 法 采用 scrollTo 来 实现 。 田 











外 ， 它 还 可 以 采用 改变 布局 的 方式 来 实现 ， 这 里 仅 仪 是 为 了 演示 ， 所 以 
就 选择 了 动画 的 方式 ， 核 心 代码 如 下 所 示 。 





mLastY = y; 


return true; 


} 


通过 上 述 代 码 可 以 看 出 ， 这 一 全 屏 滑动 的 效果 实现 起 来 相当 简单 。 
首先 我 们 通过 getRawX 和 getRawY 方 法 来 获取 手指 当前 的 坐标 ， 注 意 不 
能 使 用 getX 和 getY 方 法 ， 因 为 这 个 是 要 全 屏 滑 动 的 ， 所 以 需要 获取 当前 
点 击 事件 在 屏幕 中 的 坐标 而 不 是 相对 于 View 本 喘 的 坐标 ;其 次 ， 我 们 要 
得 到 两 次 滑动 之 间 的 位 移 ， 有 了 这 个 位 移 就 可 以 移动 当前 的 View， 移 动 
方法 采用 的 是 动画 兼容 库 nineoldandroids 中 的 ViewHelper 类 所 提供 的 
setTranslationX 和 setTranslationY 方 法 。 实 际 上 ，ViewHelper 类 提供 了 一 
系列 get/set 方 法 ， 因 为 View 的 setTranslationX 和 setTranslationY 只 能 在 
Android 3.0 及 其 以 上 版 本 才能 使 用 ， 但 是 ViewHelper 所 提供 的 方法 是 没 
有 版 本 要 求 的 ， 与 此 类 似 的 还 有 setX、setScaleX、setAlpha 等 方法 ， 这 
一 系列 方法 实际 上 是 为 属性 动画 服务 的 ， 更 详细 的 内 容 会 在 第 5 章 进行 
进一步 的 介绍 。 这 个 自 定义 View 可 以 在 2.x 及 其 以 上 版 本 工作 ， 但 是 由 
于 动画 的 性 质 ， 如 果 给 它 加 上 onClick 事 件 ， 那 么 在 3.0 以 下 版 本 它 将 无 
法 在 新 位 置 啊 应 用 户 的 点 击 ， 这 个 问题 在 前 面 已 经 提 到 过 。 

















3.3 $E 


知道 了 View 的 滑动 ， 我 们 还 要 知道 如 何 实现 View 的 弹性 滑动 ， 比 
较 生 人 硬 地 滑动 过 去 ， 这 种 方式 的 用 户 体 验 实在 太 差 了 ， 因 此 我 们 要 实现 
渐 近 式 滑动 。 那 么 如 何 实 现 弹 性 滑动 呢 ?” 其 实 实现 方法 有 很 多 ， 但 是 它 
们 都 有 一 个 共同 思想 : 将 一 次 大 的 滑动 分 成 各 干 次 小 的 滑动 并 在 一 个 时 
间 段 内 完成 ， 弹 性 滑动 的 具体 实现 方式 有 很 多 ， 比 如 通过 Scroller、 
Handler#postDelayed 以 及 Thread#sleep 等 ， 下 面 一 一 进行 介绍 。 














3.3.1 ”使 用 Scroller 


Scroller 的 使 用 方法 在 3.1.4 节 中 已 经 进行 了 介绍 ， 下 面 我 们 来 分 析 一 
下 它 的 源码 ， 从 而 探究 为 什么 它 能 实现 View 的 弹性 滑动 。 


Scroller scroller = new Scroller(mContext); 

// 绥 慢 深 动 到 指定 位 置 

private void smoothScrollTo(int destX,int destY) { 
int scrollxX = getScrollXx(); 
int deltaX = destX -scrollx; 
// 1000ms 内 滑 向 destX， 效 果 就 是 慢 慢 滑 动 
mScroller.startScroll(scrollx,0,deltax,0,1000); 
invalidate(); 

Í 

@Override 


public void computeScroll() { 


if (mScroller.computeScrolloffset()) { 
scrollTo(mScroller.getCurrX(),mScroller.getCurry( 


postInvalidate(); 


上 面 是 Scroller 的 典型 的 使 用 方法 ， 这 里 先 描 述 它 的 工作 原理 : 当 我 
们 构造 一 个 Scroller 对 象 并 且 调 用 它 的 startScroll 方 法 时 ，Scroller 内 部 其 
实 什 么 也 没 做 ， 它 只 是 保存 了 我 们 传递 的 几 个 参数 ， 这 几 个 参数 从 
startScroll 的 原型 上 就 可 以 看 出 来 ， 如 下 所 示 。 


public void startScroll(int startX,int startY,int dx,int dy,i 
mMode = SCROLL_MODE; 
mFinished = false; 
mDuration = duration; 
mStartTime = AnimationUtils.currentAnimationTimeMillis(); 
mStartX = startx; 
mStartY = startyY; 
mFinalX = startX + dx; 
mFinalY = startY + dy; 
mDeltaxX = dx; 
mDeltaY = dy; 


mDurationReciprocal = 1.0f / (float) mDuration; 


这 个 方法 的 参数 含义 很 清楚 ，startX 和 startY 表 示 的 是 滑动 的 起 点 ， 
dx 和 dy 表示 的 是 要 请 动 的 距离 ， 而 duration 表 示 的 是 滑动 时 间 ， 即 整个 
滑动 过 程 完 成 押 需 要 的 时 间 ， 注 意 这 里 的 滑动 是 指 View 内 容 的 滑动 而 非 











View 本 号 位 置 的 改变 。 可 以 看 到 ， 仅 仅 调 用 startScrol] 方 法 是 无 法 让 
View 滑 动 的 ， 因 为 它 内 部 并 没有 做 滑动 相关 的 事 ， 那 么 Scroller 到 的 是 
如 何 让 View 弹 性 滑动 的 呢 ? 管 案 就 是 startScroll 方 法 下 面 的 invalidate 方 
法 ， 虽 然 有 点 不 可 思议 ,但 是 的 确 是 这 样 的 。invalidate 方 法 会 导致 View 
重 绘 ， 在 View 的 draw 方 法 中 又 会 去 调用 computeScroll 方 法 ， 
computeScroll 方 法 在 View 中 是 一 个 空 实 现 ， 因 此 需要 我 们 自己 去 实现 ， 
上 面 的 代码 已 经 实现 了 computeScroll 方 法 。 正 是 因为 这 个 computeScroll 
方法 ，View 才 能 实现 弹性 滑动 。 这 看 起 来 还 是 很 抽象 ， 其 实 这 样 的 : 当 
View 重 绘 后 会 在 draw 方 法 中 调用 computeScroll， 而 computeScrol 又 会 去 
向 Scroller 获 取 当 前 的 scrolX 和 scrollY; 然后 通过 scrollTo 方 法 实现 滑 

动 ; 接着 又 调用 postInvalidate 方 法 来 进行 第 二 次 重 绘 ， 这 一 次 重 绘 的 过 
程 和 第 一 次 重 绘 一 样 ， 还 是 会 导致 computeScrol 方 法 被 调用 ; 然后 继续 
向 Scroller 获 取 当 前 的 scrolX 和 scrollY， 并 通过 scrollTo 方 法 滑动 到 新 的 
位 置 ， 如 此 反复 ， 直 到 整个 滑动 过 程 结束 。 














我 们 再 看 一 下 Scroller 的 computeScrollOffset 方 法 的 实现 ， 如 下 所 


/** 
* Call this when you want to know the new location. If it r 
* the animation is not yet finished. 
ir 

public boolean computeScrollOffset() { 


int timePassed = (int) (AnimationUtils.currentAnimationTim 
mStartTime) ; 


if (timePassed < mDuration) { 


switch (mMode) { 

case SCROLL_MODE: 
final float x = mInterpolator.getiInterpol 
mDurationReciprocal); 
mCurrX = mStartX + Math.round(x * mDeltax 
mCurrY = mStartY + Math.round(x * mDeltayY 


break; 


} 


return true; 


} 





是 不 是 突然 就 明日 了? 这 个 方法 会 根据 时 间 的 流逝 来 计算 出 当前 的 
scrollX 和 scrollY 的 值 。 计 算 方 法 也 很 简单 ， 大 意 就 是 根据 时 间 流 挝 的 百 
分 比 来 算出 scrollX 和 scrollY 改 变 的 百分比 并 计算 出 当前 的 值 ， 这 个 过 程 
类 似 于 动画 中 的 插值 器 的 概念 ， 这 里 我 们 先 不 去 深究 这 个 具体 过 程 。 这 
个 方法 的 返回 值 也 很 重要 ， 它 返回 true 表 示 滑 动 还 未 结束 ，false 则 表示 
滑动 已 经 结束 ， 因 此 当 这 个 方法 返回 true 时 ， 我 们 要 继续 进行 View 的 清 
ayo 














通过 上 面 的 分 析 ， 我 们 应 该 明白 Scroller 的 工作 原理 了 ， 这 里 做 一 下 
概括 : Scroller 本 身 并 不 能 实现 View 的 滑动 ， 它 需要 配合 View 的 
computeScroll 方 法 才能 完成 弹性 滑动 的 效果 ， 它 不 断 地 让 View 重 绘 ， 而 
每 一 次 重 绘 距 滑动 起 始 时 间 会 有 一 个 时 间 间 隔 ， 通 过 这 个 时 间 间 隔 
Scroller 就 可 以 得 出 View 当 前 的 滑动 位 置 ， 知 道 了 滑动 位 置 就 可 以 通过 
scrollTo 方 法 来 完成 View 的 滑动 。 束 这 样 ，View 的 每 一 次 重 绘 都 会 导致 
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是 Scroller 的 工作 机 制 。 由 此 可 见 ，Scroller 的 设计 思想 是 多 么 值得 称 

赞 ， 整 个 过 程 中 它 对 View 没 有 丝 晓 的 引用 ， 甚 至 在 它 内 部 连 计 时 右 都 没 
AA 








3.3.2 ”通过 动画 


动画 本 身 就 是 一 种 渐 近 的 过 程 ， 因 此 通过 它 来 实现 的 滑动 天 然 就 具 
有 弹性 效果 ， 比 如 以 下 代码 可 以 让 一 个 View 的 内 容 在 100ms 内 向 左 移动 
100 像 素 。 


ObjectAnimator.ofFloat(targetView, "translationx",0,100).setDu 
(100).start(); 


不 过 这 里 想 说 的 并 不 是 这 个 问题 ， 我 们 可 以 利用 动画 的 特性 来 实现 
一 些 动画 不 能 实现 的 效果 。 LE 我 们 也 想 模 仿 Scroller 来 
实现 View 的 弹性 滑动 ， 那 么 利用 动画 的 特性 ， 我 们 可 以 采用 如 下 方式 来 
实现 : 


final int startX = 0; 


final int deltaX = 100; 


ValueAnimator animator = ValueAnimator.ofInt(0,1).setDuration 
animator .addUpdateListener(new AnimatorUpdateListener() { 
@Override 
public void onAnimationUpdate(ValueAnimator animator) { 
float fraction = animator.getAnimatedFraction(); 


mButton1.scrollTo(startX + (int) (deltaX * fracti 


+); 


animator.start(); 


在 上 述 代码 中 ， 我 们 的 动画 本 质 上 没有 作用 于 任何 对 象 上 ， 它 只 是 
在 1000ms 内 完成 了 整个 动画 过 程 。 利 用 这 个 特性 ， 我 们 残 可 以 在 动画 的 
每 一 帧 到 来 时 获取 动画 完成 的 比例 ， 然 后 再 根据 这 个 比例 计算 出 当前 
View 所 要 滑动 的 距离 。 注 意 ， 这 里 的 滑动 针对 的 是 View 的 内 容 而 非 
View 本 里 。 可 以 发 现 ， 这 个 方法 的 思想 其 实 和 Scroller 比 较 类 似 ， 都 是 
通过 改变 一 个 百分比 配合 scrollTo 方 法 来 完成 View 的 滑动 。 需 要 说 明 一 
点 ， 采 用 这 种 方法 除了 能 够 完成 弹性 滑动 以 外 ， 还 可 以 实现 其 他 动画 效 
果 ， 我 们 完全 可 以 在 onAnimationUpdate 方 法 中 加 上 我 们 想 要 的 其 他 操 
ee 


3.3.3 ”使 用 延 时 案 略 


本 节 介 绍 另外 一 种 实现 弹性 滑动 的 方法 ， 那 就 是 延 时 策略 。 它 的 核 
心思 想 是 通过 发 送 一 系列 延 时 消息 从 而 达到 一 种 渐 近 式 的 效果 ， 有 具体 来 
说 可 以 使 用 Handler 或 View 的 postDelayed 方 法 ， 也 可 以 使 用 线程 的 sleep 
方法 。 对 于 postDelayed 方 法 来 说 ， 我 们 可 以 通过 它 来 延 时 发 送 一 个 消 
轧 ， 然 后 在 消息 中 来 进行 View 的 滑动 ， 如 采 接 连 不 断 地 发 送 这 种 延 时 消 
轧 ， 那 么 就 可 以 实现 弹性 滑动 的 效果 。 对 于 sleep 方 法 来 说 ， 通 过 在 
while 循 环 中 不 断 地 滑动 View 和 sleep， 就 可 以 实现 弹性 滑动 的 效果 。 





下 面 采 用 Handler 来 做 个 示例 ， 其 他 方法 请 读者 自行 去 尝试， 思想 
都 是 类 似 的 。 下 面 的 代码 在 大 约 1000ms 内 将 View 的 内 容 向 左 移 动 了 100 
像素 ， 代 码 比 较 简 单 ， 就 不 再 详细 介绍 了 。 之 所 以 说 大 约 1000ms， 是 因 


为 采用 这 种 方式 无 法 精确 地 定时 ， 原 因 是 系统 的 消息 调度 也 是 需要 时 间 
的 ， 并 且 所 需 时 间 不 定 。 








上 面 几 种 弹性 滑动 的 实现 方法 ， 在 介绍 中 侧重 更 多 的 是 实现 思想 ， 
在 实际 使 用 中 可 以 对 其 灵活 地 进行 扩展 从 而 实现 更 多 复杂 的 效果 。 











3.4 View 的 事件 分 发 机 制 


上 面 几 节 介 绍 了 View 的 基础 知识 以 及 View 的 滑动 ， 本 节 将 介绍 
View 的 一 个 核心 知识 点 : 事件 分 发 机 制 。 事 件 分 发 机 制 不 仅仅 是 核心 知 
识 点 更 是 难点 ， 不 少 初学 者 其 至 中 级 开发 者 面 对 这 个 问题 时 都 会 觉得 困 
惑 。 另 外 ，View 的 妃 一 大 难题 滑动 名 突 ， 它 的 解决 方法 的 理论 基础 就 是 
事件 分 友 机 制 ， 因 此 掌握 好 View 的 事件 分 发 机 制 是 十 分 重要 的 。 本 市 将 
深入 介绍 View 的 事件 分 发 机 制 ， 在 3.4.1 节 会 对 事件 分 发 机 制 进行 概括 性 
地 介绍 ， 而 在 3.4.2 市 将 结合 系统 源码 去 进一步 分 析 事 件 分 友 机 制 。 


3.4.1 点击 事 件 的 传递 规则 


在 介绍 点 击 事件 的 传递 规则 之 前 ， 首 先 我 们 要 明白 这 里 要 分 析 的 对 
象 就 是 MotionEvent， 即 点 击 事件 ， 关 于 MotionEvent 在 3.1 节 中 已 经 进行 
了 介绍 。 所 谓 点 击 事件 的 事件 分 发 ， 其 实 就 是 对 MotionEvent 事 件 的 分 
发 过 程 ， 即 当 一 个 MotionEvent 产 生 了 以 后 ， 系 统 需 要 把 这 个 事件 传递 
给 一 个 具体 的 View， 而 这 个 传递 的 过 程 束 是 分 发 过 程 。 点 击 事 件 的 分 发 
过 程 由 三 个 很 重要 的 方法 来 共同 完成 : dispatchTouchEvent、 
onInterceptTouchEvent 和 onTouchEvent， 下 面 我 们 先 介 绍 一 下 这 几 个 方 
法 

















public boolean dispatchTouchEvent(MotionEvent ev) 


用 来 进行 事件 的 分 发 。 如 果 事 件 能 够 传递 给 当前 View， 那 么 此 方法 
一 定 会 被 调用 ， 返 回 结果 受 当 前 View 的 onTouchEvent 和 下 级 View 的 





dispatchTouchEvent 方 法 的 影响 ， 表 示 是 人 否 消 耗 当前 事件 。 
public boolean onInterceptTouchEvent(MotionEvent event) 


在 上 述 方法 内 部 调用 ， 用 来 判断 是 否 拦截 茶 个 事件 ， 如 果 当 前 View 
拦 蕉 了 茶 个 事件 ， 那 么 在 同一 个 事件 序列 当中 ， 此 方法 不 会 被 再 次 调 
用 ， 返 回 结果 表示 是 侣 拦截 当前 事件 。 














public boolean onTouchEvent(MotionEvent event) 


在 dispatchTouchEvent 方 法 中 调用 ， 用 来 处 理 点 击 事件 ， 返 回 结果 
表示 是 售 消 耗 当 前 事件 ， 如 果 不 消耗 ， 则 在 同一 个 事件 序列 中 ， 当 前 
View 无 法 再 次 接收 到 事件 。 





上 述 三 个 方法 到 底 有 什么 区 别 呢 ? 它们 是 什么 关系 呢 ? 其 实 它 们 的 
关系 可 以 用 如 下 伪 代 码 表 示 : 


public boolean dispatchTouchEvent(MotionEvent ev) { 
boolean consume = false; 
if (onInterceptTouchEvent(ev)) { 
consume = onTouchEvent(ev); 
} else { 
consume = child.dispatchTouchEvent (ev); 
j 


return consume; 


} 


上 述 伪 代 码 已 经 将 三 者 的 关系 表现 得 淋漓 尽 致 。 通 过 上 面 的 伪 代 
码 ， 我 们 也 可 以 大 致 了 解 点 击 事件 的 传递 规则 : 对 于 一 个 根 ViewGroup 


来 说 ， 点 击 事件 产生 后 ， 首 先 会 传递 给 它 ， 这 时 它 的 
dispatchTouchEvent 束 会 被 调用 ， 如 果 这 个 ViewGroup 的 
onInterceptTouchEvent 方 法 返回 true 就 表示 它 要 拦截 当前 事件 ， 接 着 事件 
就 会 交 给 这 个 ViewGroup 处 理 ， 即 它 的 onTouchEvent 方 法 就 会 被 调 用 ; 

如 果 这 个 ViewGroup 的 onInterceptTouchEvent 方 法 返回 false 就 表示 它 不 拦 
截 当前 事件 ， 这 时 当前 事件 就 会 继续 传递 给 它 的 子 元 素 ， 接 着 子 元 素 的 
dispatchTouchEvent 方 法 就 会 被 调用 ， 如 此 反复 直到 事件 被 最 终 处 理 。 














当 一 个 View 需 要 处 理事 件 时 ， 如 果 它 设置 了 OnTouchListener， 那 

么 OnTouchListener 中 的 onTouch 方 法 会 被 回调 。 这 时 事件 如 何 处 理 还 要 
看 onTouch 的 返回 值 ， 如 果 返 回 false， 则 当前 View 的 onTouchEvent 方 法 
会 被 调用 ;如果 返回 true， 那 么 onTouchEvent 方 法 将 不 会 被 调用 。 由 此 
可 见 ， 给 View 设 置 的 OnTouchListener， 其 优先 级 比 onTouchEvent 要 高 。 
在 onTouchEvent 方 法 中 ， 如 果 当 前 设置 的 有 OnClickListener， 那 么 它 的 
onClick 方 法 会 被 调用 。 可 以 看 出 ， 平 时 我 们 常用 的 OnClickListener， 其 
优先 级 最 低 ， 即 处 于 事件 传递 的 尾 端 。 


当 一 个 点 击 事件 产生 后 ， 它 的 传递 过 程 遵循 如 下 顺序 : Activity -> 
Window -> View， 即 事件 总 是 先 传递 给 Activity，Activity 再 传递 给 
Window， 最 后 Window 再 传递 给 顶级 View。 顶 级 View 接 收 到 事件 后 ， 
就 会 按照 事件 分 发 机 制 去 分 发 事件 。 考 虑 一 种 情况 ， 如 果 一 个 View 的 
onTouchEvent 返 回 false， 那 么 它 的 父 容器 的 onTouchEvent 将 会 被 调用 ， 
依 此 类 推 。 如 果 所 有 的 元 素 都 不 处 理 这 个 事件 ， 那 么 这 个 事件 将 会 最 终 
传递 给 Activity 处 理 ， 即 Activity 的 onTouchEvent 方 法 会 被 调用 。 这 个 过 
星 其 实 也 很 好 理解 ， 我 们 可 以 换 一 种 思路 ， 假 如 点 击 事件 是 一 个 难题 ， 
这 个 难题 最 终 被 上 级 领导 分 给 了 一 个 程序 员 去 处 理 〈 这 是 事件 分 发 过 
RE) ， 结 果 这 个 程序 员 摘 不 定 (onTouchEvent 返 回 了 false) ， 现 在 该 怎 


么 办 呢 ?” 难 题 必须 要 解决 ， 那 只 能 交 给 水 平 更 高 的 上 级 解决 《上 级 的 
onTouchEvent 被 调用 ) ， 如 果 上 级 再 搞 不 定 ， 那 只 能 交 给 上 级 的 上 级 去 
解决 ， 就 这 样 将 难题 一 层 层 地 同上 抛 ， 这 是 公司 内 部 一 种 很 常见 的 处 理 
问题 的 过 程 。 从 这 个 角度 来 看 ，View 的 事件 传递 过 程 还 是 很 贴近 现实 
的 ， 毕 竟 程 序 员 也 生活 在 现实 中 。 


关于 事件 传递 的 机 制 ， 这 里 给 出 一 些 结论 ， 根 据 这 些 结论 可 以 更 好 
地 理解 整个 传递 机 制 ， 如 下 所 示 。 





(1) 同一 个 事件 序列 是 指 从 手指 接触 屏幕 的 那 一 刻 起 ， 到 手指 离 
开 屏 幕 的 那 一 刻 结束 ， 在 这 个 过 程 中 所 产生 的 一 系列 事件 ， 这 个 事件 序 
列 以 down 事 件 开 始 ， 中 间 含 有 数量 不 定 的 move 事 件 ， 最 终 以 up 事件 结 
Ro 











(2) 正常 情况 下 ， 一 个 事件 序列 只 能 被 一 个 View 拦 截 且 消耗 。 这 
一 条 的 原因 可 以 参考 〈3) ， 因 为 一 旦 一 个 元 素 拦截 了 某 此 事件 ， 那 么 
同一 个 事件 序列 内 的 所 有 事件 都 会 直接 交 给 它 处 理 ， 因 此 同一 个 事件 序 
列 中 的 事件 不 能 分 别 由 两 个 View 同 时 处 理 ， 但 是 通过 特殊 手段 可 以 做 
到 ， 比 如 一 个 View 将 本 该 自己 处 理 的 事件 通过 onTouchEvent 强 行 传递 给 
其 他 View 处 理 。 











(3) 某 个 View 一 旦 决定 拦截 ， 那 么 这 一 个 事件 序列 都 只 能 由 它 来 
处 理 〈( 如 果 事 件 序列 能 够 传递 给 它 的话 ) ， 并 且 它 的 
onInterceptTouchEvent 不 会 再 被 调用 。 这 条 也 很 好 理解 ， 就 是 说 当 一 个 
View 决 定 拦 截 一 个 事件 后 ， 那 么 系统 会 把 同一 个 事件 序列 内 的 其 他 方法 
都 直接 交 给 它 来 处 理 ， 因 此 就 不 用 再 调用 这 个 View 的 


onInterceptTouchEvent 去 询问 它 是 否 要 拦截 了 。 





(4) 某 个 View 一 旦 开始 处 理事 件 ， 如 果 它 不 消耗 ACTION_DOWN 
事件 ConTouchEventik e] Y false) ， 那 么 同一 事件 序列 中 的 其 他 事件 都 
不 会 再 交 给 它 来 处 理 ， 并 有 旦 事件 将 重新 交 由 它 的 父 元 素 去 处 理 ， 即 父 元 
素 的 onTouchEvent 会 被 调用 。 意 思 就 是 事件 一 旦 交 给 一 个 View 处 理 ， 那 
么 它 台 必须 消耗 挤 ， 人 否则 同一 事件 序列 中 剩 下 的 事件 就 不 再 交 给 它 来 处 
理 了 ， 这 就 好 比 上 级 交 给 程序 员 一 件 事 ， 如 果 这 件 事 没有 处 理 好 ， 短 期 
内 上 级 就 不 敢 再 把 事情 交 给 这 个 程序 员 做 了 ， 二 者 是 类 似 的 道理 。 























(5) 如 果 View 不 消耗 除 ACTION_DOWN 以 外 的 其 他 事件 ， 那 么 这 
个 点 击 事件 会 消失 ， 此 时 父 元 素 的 onTouchEvent 并 不 会 被 调用 ， 并 且 当 
前 View 可 以 持续 收 到 后 续 的 事件 ， 最 终 这 些 消失 的 点 击 事 件 会 传递 给 
Activity 处 理 。 


(6) ViewGroup 默 认 不 拦截 任何 事件 。Android 源 码 中 ViewGroup 
的 onInterceptTouch-Event 方 法 默认 返回 false。 


(7) View 没有 onInterceptTouchEvent 方 法 ， 一 旦 有 点 击 事件 传递 给 
它 ， 那 么 它 的 onTouchEvent 方 法 就 会 被 调用 。 


(8) View 的 onTouchEvent 默 认 都 会 消耗 事件 《返回 true) ， 除 非 它 
是 不 可 点 击 的 (clickable 和 ]longClickable 同 时 为 false) 。View 的 
longClickable 属 性 默认 都 为 false，clickable 属 性 要 分 情况 ， 比 如 Button 的 
clickable 属 性 默认 为 true， 而 TextView 的 clickable 属 性 默认 为 false。 


(9) View 的 enable 属 性 不 影响 onTouchEvent 的 默认 返回 值 。 哪 怕 一 
个 View 是 disable 状 态 的 ， 只 要 它 的 clickable 或 者 longClickable 有 一 个 为 
true， 那 么 它 的 onTouchEvent 就 返回 true。 


(10) onClick 会 发 生 的 前 提 是 当前 View 是 可 点 击 的 ， 并 且 它 收 到 


了 down 和 up 的 事件 。 


(11) 事件 传递 过 程 是 由 外 向 内 的 ， 即 事件 总 是 先 传递 给 父 元 素 ， 
然后 再 由 父 元 素 分 发 给 子 View， 通 过 requestDisallowInterceptTouchEvent 
方法 可 以 在 子 元 素 中 干预 父 元 素 的 事件 分 发 过 程 ， 但 是 
ACTION_DOWN 事 件 除外 。 


3.4.2 事件 分 发 的 源码 解析 


上 一 节 分 析 了 View 的 事件 分 发 机 制 ， 本 节 将 会 从 源码 的 角度 去 进 一 
步 分 析 、 证 实 上 面 的 结论 。 


1. Activity 对 点 击 事件 的 分 发 过 程 


点 击 事件 用 MotionEvent 来 表示 ， 当 一 个 点 击 操作 发 生 时 ， 事 件 最 
先 传递 给 当前 Activity， 由 Activity 的 dispatchTouchEvent 来 进行 事件 派 
发 ， 具 体 的 工作 是 由 Activity 内 部 的 Window 来 完成 的 。Window 会 将 事件 
传递 给 decor view, decor view—ik#ie SH AMR Aa CB 
setContentView 所 设置 的 View 的 父 容器 ) ， 通 过 
Activity.getWindow.getDecorView() 可 以 获得 。 我 们 先 从 Activity 的 
dispatchTouchEvent 开 始 分 析 。 


源码 : Activity#dispatchTouchEvent 


public boolean dispatchTouchEvent(MotionEvent ev) { 
if (ev.getAction() == MotionEvent.ACTION_DOWN) { 


onUserInteraction(); 


if (getWindow().superDispatchTouchEvent(ev)) { 
return true; 
t 


return onTouchEvent (ev); 


} 


现在 分 析 上 面 的 代码 。 首 先 事件 开始 交 给 Activity 所 附属 的 Window 
进行 分 发 ， 如 果 人 返回 true， 整 个 事件 循环 就 结束 了 ， 返 回 false 意 味 着 事 
件 没 人 处 理 ， 所 有 View 的 onTouchEvent 都 返回 了 false， 那 么 Activity 的 
onTouchEvent 就 会 被 调用 。 





接 下 来 看 Window 是 如 何 将 事件 传递 给 ViewGroup 的 。 通 过 源码 我 们 
知道 ，Window 是 个 抽象 类 ， 而 Window 的 superDispatchTouchEvent 方 法 
也 是 个 抽象 方法 ， 因 此 我 们 必须 找到 Window 的 实现 类 才 行 。 


源码 : Window#superDispatchTouchEvent 


public abstract boolean superDispatchTouchEvent(MotionEvent e 


那么 到 底 Window 的 实现 类 是 什么 呢 ? 其 实 是 PhoneWindow， 这 一 
点 从 Window 的 源码 中 也 可 以 看 出 来 ， 在 Window 的 说 明 中 ， 有 这 么 一 有 段 
T 


Abstract base class for a top-level window look and behavior policy. An 
instance of this class should be used as the top-level view added to the 
window manager. It provides standard UI policies such as a background, title 


area, default key processing, etc. 


The only existing implementation of this abstract class is android. 


policy. PhoneWindow,which you should instantiate when needing a Window. 
Eventually that class will be refactored and a factory method added for 
creating Window instances without knowing about a particular 


implementation. 


上 面 这 段 话 的 大 概 意思 是 : Window 类 可 以 控制 顶级 View 的 外 观 和 
行为 策略 ， 它 的 唯一 实现 位 于 android.policy.PhoneWindow 中 ， 当 你 要 实 
例 化 这 个 Window 类 的 时 候 ， 你 并 不 知道 它 的 细节 ， 因 为 这 个 类 会 被 重 
构 ， 只 有 一 个 工厂 方法 可 以 使 用 。 尺 管 这 看 起 来 有 点 模糊 ， 不 过 我 们 可 
以 看 一 下 android.policy.PhoneWindow 这 个 类 ， 尽 管 实例 化 的 时 候 此 类 会 
被 重 构 ， 仅 是 重 构 而 已 ， 功 能 是 类 似 的 。 





由 于 Window 的 唯一 实现 是 PhoneWindow， 因 此 接 下 来 看 一 下 
PhoneWindow 是 如 何 处 理 点 击 事 件 的 ， 如 下 所 示 。 


源码 : PhoneWindow#superDispatchTouchEvent 


public boolean superDispatchTouchEvent(MotionEvent event) { 


return mDecor.superDispatchTouchEvent (event ); 


到 这 里 逻辑 就 很 清晰 了 ，PhoneWindow 将 事件 直接 传递 给 了 
DecorView， 这 个 DecorView 是 什么 呢 ?” 请 看 下 面 : 


private final class DecorView extends FrameLayout implements 
faceTaker 

// This is the top-level view of the window,containing the wi 
private DecorView mDecor; 


@Override 


public final View getDecorView() { 
if (mDecor == null) { 
installDecor(); 
J; 
return mDecor, 


} 


我 们 知道 ， 通 过 
((ViewGroup)getWindow().getDecorView().find ViewBylId(android.R.id.conti 
Ay Ut A ASK AM Activity ATA View, iX“SmDecorin Awe 
getWindow().getDecorView() 返 回 的 View， 而 我 们 通过 setContentView 设 
置 的 View 是 它 的 一 个 子 View。 目 前 事件 传递 到 了 DecorView 这 里 ， 由 于 
DecorView 继 承 自 FrameLayout 且 是 父 View， 所 以 最 终 事 件 会 传递 给 
View。 换 人 句 话 来 襄 ， 事 件 肯定 会 传递 到 View， 不 然 应 用 如 何 响应 点 击 
事件 呢 ? 不 过 这 不 是 我 们 的 重点 ， 重 点 是 事件 到 了 View 以 后 应 该 如 何 传 
递 ， 这 对 我 们 更 有 用 。 从 这 里 开始 ， 事 件 已 经 传递 到 顶级 View 了 ， 即 在 
Activity 中 通过 setContentView 所 设置 的 View， 男 外 顶级 View 也 叫 根 
View， 顶 级 View 一 般 来 说 都 是 ViewGroup。 





3. 顶级 View 对 点 击 事件 的 分 发 过 程 


关于 点 击 事件 如 何在 View 中 进行 分 友 ， 上 一 市 已 经 做 了 详细 的 介 
绍 ， 这 里 再 大 致 回顾 一 下 。 点 击 事件 达到 顶级 View 一 般 是 一 个 
ViewGroup) 以 后 ， 会 调用 ViewGroup 的 dispatchTouchEvent 方 法 ， 然 后 
的 逻辑 是 这 样 的 ， 如 果 顶 级 ViewGroup 拦 截 事 件 即 onInterceptTouchEvent 
返回 true， 则 事件 由 ViewGroup 处 理 ， 这 时 如 果 ViewGroup 的 
mOnTouchListener 被 设置 ， 则 onTouch 会 被 调用 ， 人 否则 onTouchEvent 会 
补 调 用 。 也 就 是 说 ， 如 果 都 提供 的 话 ，onTouch 会 屏蔽 挥 


onTouchEvent. 7£onTouchEvent#, WRA SmOnClickListener, Il) 
onClick 会 被 调用 。 如 果 顶 级 ViewGroup 不 拦截 事件 ， 则 事件 会 传递 给 它 
所 在 的 点 击 事件 链 上 的 子 View， 这 时 子 View 的 dispatchTouchEvent 会 被 
调用 。 到 此 为 止 ， 事件 已 经 从 顶级 View 传 递 给 了 下 一 层 View， 接 下 来 
的 传递 过 程 和 顶级 View 是 一 至 的， 如 此 循环 ， 完 成 整个 事件 的 分 发 。 


首先 看 ViewGroup 对 点 击 事件 的 分 发 过 程 ， 其 主要 实现 在 
ViewGroup 的 dispatchTouch-Event 方 法 中 ， 这 个 方法 比较 长 ， 这 里 分 段 
说 明 。 先 看 下 面 一 段 ， 很 显然 ， 它 描述 的 是 当前 View 是 人 否 拦截 点 击 事情 
这 个 逻辑 。 








// Check for interception. 
final boolean intercepted; 
if (actionMasked == MotionEvent .ACTION_DOWN 
|| mFirstTouchTarget != null) { 
final boolean disallowIntercept = (mGroupFlags & FLAG_DIS. 
if (!disallowIntercept) { 
intercepted = onInterceptTouchEvent (ev); 
ev.setAction(action); // restore action in case i 
} else { 
intercepted = false; 
} 
} else { 
// There are no touch targets and this action is not an i 
// so this view group continues to intercept touches. 


intercepted = true; 


从 上 面 代码 我 们 可 以 看 出 ，ViewGroup 在 如 下 两 种 情况 下 会 判断 是 
否 要 拦截 当前 事件 事件 类 型 为 ACTION_DOWN 或 者 mFirstTouchTarget 
!= null。ACTION_DOWN 事 件 好 理解 ， 那 么 mFirstTouchTarget != null 
什么 意思 呢 ? 这 个 从 后 面 的 代码 逻辑 可 以 看 出 来 ， 当 事件 由 ViewGroup 
的 子 元 素 成 功 处 理 时 ，mFirstTouchTarget 会 被 赋值 并 指向 子 元 素 ， 换 种 
方式 来 说 ， 当 ViewGroup 不 拦截 事件 并 将 事件 交 由 子 元 又 处 理 时 











mFirstTouchTarget != nul。 反 过 来 ， 一 旦 事件 由 当前 ViewGroup 拦 截 
时 ，mFirstTouchTarget != null 就 不成立 。 那 么 当 ACTION_MOVE 和 
ACTION_UP 事 件 到 来 时 ， 由 于 (actionMasked = MotionEvent. 


ACTION_DOWN || mFirstTouchTarget != null) 这 个 条 件 为 false， 将 导致 
ViewGroup 的 onInterceptTouchEvent 不 会 再 被 调用 ， 并 且 同 一 序列 中 的 其 
他 事件 都 会 默认 交 给 它 处 理 。 


当然 ， 这 里 有 一 种 特殊 情况 ， 那 就 是 
FLAG_DISALLOW_INTERCEPT 标 记 位 ， 这 个 标记 位 是 通过 
requestDisallowInterceptTouchEvent 方 法 来 设置 的 ， 一 般 用 于 子 View 中 。 
FLAG_DISALLOW_INTERCEPT 一 旦 设置 后 ，ViewGroup 将 无 法 拦截 除 
了 ACTION_DOWN 以 外 的 其 他 点 击 事件 。 为 什么 说 是 除了 
ACTION_DOWN 以 外 的 其 他 事件 呢 ? 这 是 因为 ViewGroup 在 分 发 事件 
时 ， 如 果 是 ACTION_DOWN 就 会 重 置 FLAG_DISALLOW_INTERCEPT 
这 个 标记 位 ， 将 导致 子 View 中 设置 的 这 个 标记 位 无 效 。 因 此 ， 当 面 对 
ACTION_DOWN 事 件 时 ，ViewGroup 总 是 会 调用 自己 的 
onInterceptTouchEvent 方 法 来 询问 自己 是 否 要 拦截 事件 ， 这 一 点 从 源码 
中 也 可 以 看 出 来 。 在 下 面 的 代码 中 ，ViewGroup 会 在 ACTION_DOWN 事 
件 到 来 时 做 重 置 状 态 的 操作 ， 而 在 resetTouchState 方 法 中 会 对 
FLAG_DISALLOW_INTERCEPT 进 行 重 置 ， 因 此 子 View 调 用 request- 
DisallowInterceptTouchEvent 方 法 并 不 能 影响 ViewGroup 对 








ACTION_DOWN 事 件 的 处 理 。 


// Handle an initial down. 

if (actionMasked == MotionEvent.ACTION_DOWN) { 
// Throw away all previous state when starting a new touc 
// The framework may have dropped the up or cancel event 
// due to an app switch,ANR,or some other state change. 
cancelAndClearTouchTargets(ev); 


resetTouchState(); 


从 上 面 的 源码 分 析 ， 我 们 可 以 得 出 结论 : 当 ViewGroup 决 定 拦截 事 
件 后 ， 那 么 后 续 的 点 击 事 件 将 会 默认 交 给 它 处 理 并 且 不 再 调用 它 的 
onInterceptTouchEvent 方 法 ， 这 证 实 了 3.4.1 市 末尾 处 的 第 3 条 结论 。 
FLAG_DISALLOW_INTERCEPT 这 个 标志 的 作用 是 让 ViewGroup 不 再 拦 
截 事 件 ， 当 然 前 提 是 ViewGroup 不 拦截 ACTION_DOWN 事 件 ， 这 证 实 了 
3.4.1 节 末尾 处 的 第 11 条 结论 。 那 么 这 段 分 析 对 我 们 有 什么 价值 呢 ? 总 结 
起 来 有 两 点 : 第 一 点 ，onInterceptTouchEvent 不 是 每 次 事件 都 会 被 调用 
的 ， 如 果 我 们 想 提 前 处 理 所 有 的 点 击 事件 ， 要 选择 dispatchTouchEvent 
方法 ， 只 有 这 个 方法 能 确保 每 次 都 会 调用 ， 当 然 前 提 是 事件 能 够 传递 到 
当前 的 ViewGroup; 另外 一 点 ，FLAG_DISALLOW_INTERCEPT 标 记 位 
的 作用 给 我 们 提供 了 一 个 思路 ， 当 面 对 滑动 冲突 时 ， 我 们 可 以 是 不 是 考 
处 用 这 种 方法 去 解决 问题 ? 关于 滑动 冲突 ， 将 在 3.5 闻 进行 详细 分 析 。 

















接着 再 看 当 ViewGroup 不 拦截 事件 的 时 候 ， 事 件 会 同 下 分 发 交 由 它 
的 子 View 进 行 处 理 ， 这 段 源码 如 下 所 示 。 


final View[] children = mChildren; 


for (int i = childrenCount -1; i => 0; i--) { 
final int childIndex = customOrder 
? getChildDrawingOrder(childrenCount,1i) : i; 
final View child = (preorderedList == null) 
? children[childIndex] : preorderedList.get(chil 
if (!canViewReceivePointerEvents(child) 
|| !isTransformedTouchPointInView(x, y, child, null 
continue; 
j; 
newTouchTarget = getTouchTarget(child); 
if (newTouchTarget != null) { 
// Child is already receiving touch within its bounds 
// Give it the new pointer in addition to the ones it 
newTouchTarget.pointerIdBits |= idBitsToAssign; 
break; 
h 
resetCancelNextUpFlag(child); 
if (dispatchTransformedTouchEvent(ev, false, child, idBitsTo. 
// Child wants to receive touch within its bounds. 
mLastTouchDownTime = ev.getDownTime(); 
if (preorderedList != null) { 
// childIndex points into presorted list,find ori 
for (int j = 0; j < childrenCount; j++) { 
if (children[childIndex] == mChildren[j]) { 
mLastTouchDownIndex = j; 


break; 


} 
} else { 
mLastTouchDownIndex = childIndex; 
} 
mLastTouchDownX = ev.getX(); 
mLastTouchDownY = ev.getY(); 
newTouchTarget = addTouchTarget(child,idBitsToAssign) 
alreadyDispatchedToNewTouchTarget = true; 


break; 


} 
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由 两 点 来 衡量 : 子 元 素 是 否 在 播 动 画 和 点 击 事件 的 坐标 是 否 落 在 子 元 素 
的 区 域内 。 如 果菜 个 子 元 素 满 足 这 两 个 条 件 ， 那 么 事件 就 会 传递 给 它 来 
处 理 。 可 以 看 到 ，dispatchTransformedTouchEvent 实 际 上 调用 的 就 是 子 
元 素 的 dispatchTouchEvent 方 法 ， 在 它 的 内 部 有 如 下 一 段 内 容 ， 而 在 上 
面 的 代码 中 child 传 递 的 不 是 null， 因 此 它 会 直接 调用 子 元 素 的 
dispatchTouchEvent 方 法 ， 这 样 事件 就 交 由 子 元 素 处 理 了 ， 从 而 完成 了 
一 轮 事 件 分 发 。 











if (child == null) { 

handled = super.dispatchTouchEvent(event ); 
} else { 

handled = child.dispatchTouchEvent (event); 


如 果子 元 素 的 dispatchTouchEvent 返 回 true， 这 时 我 们 暂时 不 用 考虑 
事件 在 子 元 素 内 部 是 怎么 分 发 的 ， 那 么 mEFirstTouchTarget 融 会 被 赋值 同 
时 跳出 for 循 环 ， 如 下 所 示 。 


newTouchTarget = addTouchTarget(child, idBitsToAssign) ; 
alreadyDispatchedToNewTouchTarget = true; 


break; 


这 几 行 代码 完成 了 mFirstTouchTarget 的 赋值 并 终止 对 子 元 素 的 遍 
。 如 果子 元 素 的 dispatchTouchEvent 返 回 false，ViewGroup 就 会 把 事件 
TRE PEF TCR UREA T- TTAR) 
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其 实 mFirstTouchTarget 真 正 的 赋值 过 程 是 在 addTouchTarget 内 部 完 
成 的 ， 从 下 面 的 addTouchTarget 方 法 的 内 部 结构 可 以 看 出 ， 
mFirstTouchTarget 其 实 是 一 种 单 链 表 结 构 。mFirstTouchTarget 是 否 被 赋 
值 ， 将 直接 影响 到 ViewGroup 对 事件 的 拦截 策略 ， 如 果 
ee 。 null， 那 么 ViewGroup 就 默认 拦截 接 下 来 同一 序列 中 
所 有 的 点 击 事 件 ， 这 一 点 在 前 面 已 经 做 了 分 析 。 


private TouchTarget addTouchTarget(View child,int pointerIdBi 
TouchTarget target = TouchTarget.obtain(child,pointerIdBi 
target.next = mFirstTouchTarget; 
mFirstTouchTarget = target; 
return target; 


} 


AEE sen ee ee 天 地 处 理 ， 这 包含 两 种 情 
况 : 第 一 种 是 ViewGroup 没 有 子 元 素 ; 第 二 种 是 子 元 素 处 理 了 点 击 事 











件 ， 但 是 在 dispatchTouchEvent 中 返回 了 false， 这 一 般 是 因为 子 元 素 在 
ee ViewGroup 会 自己 处 理 
点 击 事件 ， 这 里 就 证 实 了 3.4.1 市 中 的 第 4 条 结论 ， 代 码 如 下 所 示 。 


// Dispatch to touch targets. 

if (mFirstTouchTarget == null) { 
// No touch targets so treat this as an ordinary view. 
handled = dispatchTransformedTouchEvent(ev, canceled, null, 


TouchTarget.ALL_POINTER_IDS); 


注意 上 面 这 段 代 码 ， 这 里 第 三 个 参数 child 为 null， 从 前 面 的 分 析 可 


以 知道 ， ee ett 很 显然 ， 这 里 束 转 
到 了 View 的 dispatchTouchEvent 方 法 ， 即 点 击 事件 开始 交 由 View 来 处 


理 ， 请 看 下 面 的 分 析 。 
4. View 对 点 击 事件 的 处 理 过 程 


View 对 点 击 事件 的 处 理 过 程 稍微 简单 一 些 ， 注 意 这 里 的 View 不 包 
含 ViewGroup。 先 看 它 的 dispatchTouchEvent 方 法 ， 如 下 所 示 。 





public boolean dispatchTouchEvent(MotionEvent event) { 


boolean result = false; 


if (onFilterTouchEventForSecurity(event)) { 
//noinspection SimplifiableIfStatement 
ListenerInfo li = mListenerInfo; 


if (li != null && 11.mOnTouchListener != null 


&& (mViewFlags & ENABLED MASK) == 
&& 1i.mOnTouchListener.onTouch(th 
result = true; 
Í 
if (!result && onTouchEvent(event)) { 


result = true; 


return result; 


} 


View 对 点 击 事 件 的 处 理 过 程 束 比较 简单 了 ， 因 为 View〈 这 里 不 包 
含 ViewGroup) 是 一 个 单独 的 元 素 ， 它 没有 子 元 素 因 此 无 法 向 下 传递 事 
件 ， 所 以 它 只 能 自己 处 理事 件 。 从 上 面 的 源码 可 以 看 出 View 对 点 击 事件 
的 处 理 过 程 ， 首 先 会 判 灯 有 没有 设置 OnTouchListener， 如 采 
OnTouchListener 中 的 onTouch 方 法 返回 true， 那 么 onTouchEvent 残 不 会 被 
调用 ， 可 见 OnTouchListener 的 优先 级 高 于 onTouchEvent， 这 样 做 的 好 处 
是 方便 在 外 界 处 理 点 击 事件 。 








接着 再 分 析 onTouchEvent 的 实现 。 先 看 当 View 处 于 不 可 用 状态 下 点 
击 事件 的 处 理 过 程 ， 如 下 所 示 。 很 显然 ， 不 可 用 状态 下 的 View 照 样 会 消 
耗 点 击 事件 ， 尽 管 它 看 起 来 不 可 用 。 





if ((viewFlags & ENABLED_MASK) == DISABLED) { 
if (event.getAction() == MotionEvent.ACTION_UP && (mPriva 


setPressed(false); 





接着 ， 如 果 View 设 置 有 代理 ， 那 么 还 会 执行 TouchDelegate 的 
onTouchEvent 方 法 ， 这 个 onTouchEvent 的 工作 机 制 看 起 来 和 
OnTouchListener 类 似 ， 这 里 不 深入 研究 了 。 





下 面 再 看 一 下 onTouchEvent 中 对 点 击 事件 的 具体 处 理 ， 如 下 所 示 。 











从 上 面 的 代码 来 看 ， 只 要 View 的 CLICKABLE 和 
LONG_CLICKABLE 有 一 个 为 tue， 那 么 它 就 会 消耗 这 个 事件 ， 即 
onTouchEvent 方 法 返回 true， 不 管 它 是 不 是 DISABLE 状 态 ， 这 就 证 实 了 
3.4.1 节 末尾 处 的 第 8、 第 9 和 第 10 条 结论 。 然 后 就 是 当 ACTION_UP 事 件 





发 生 时 ， 会 触发 performClick 方 法 ， 如 果 View 设 置 S OnClickListener, 
那么 performClick 方 法 内 部 会 调用 它 的 onClick 方 法 ， 如 下 所 示 。 


public boolean performClick() { 

final boolean result; 

final ListenerInfo li = mListenerInfo; 

if (li != null && 1i.mOnClickListener != null) { 
playSoundEffect(SoundEffectConstants.CLICk); 
1i.mOnClickListener.onClick(this); 
result = true; 

} else { 
result = false; 

i 

sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICK 


return result; 


View 的 LONG_CLICKABLE 属 性 默认 为 false， 而 CLICKABLE 属 性 
是 否 为 false 和 具体 的 View 有 关 ， 确 切 来 说 是 可 点 击 的 View 其 
CLICKABLE 为 true， 不 可 点 击 的 View 其 CLICKABLE 为 false， 比 如 
Button 是 可 点 击 的 ，TextView 是 不 可 点 击 的 。 通 过 setClickable 和 
setLongClickable FJ 以 分 别 改变 View 的 CLICKABLE 和 
LONG_CLICKABLE 属 性 。 男 外 ，setOnClickListener 会 自动 将 View 的 
CLICKABLE 设 为 true，setOnLongClickListener 则 会 自动 将 View 的 
LONG_CLICKABLE 设 为 tue， 这 一 点 从 源码 中 可 以 看 出 来 ， 如 下 所 
ZN o 





public void setOnClickListener(OnClickListener 1) { 
if (!isClickable()) { 
setClickable(true); 





到 这 里 ， 点 击 事件 的 分 发 机 制 的 源码 实现 已 经 分 析 完 了 ， 结 合 3.4.1 


市 中 的 理论 分 析 和 相关 结论 ， 读 者 就 可 以 更 好 地 理解 事件 分 友 了 。 在 
3.5 节 将 介绍 滑动 名 突 相关 的 知识 ， 有 具体 情况 请 看 下 面 的 分 析 。 





3.5 View 的 请 动 冲突 


本 节 开 始 介绍 View 体 系 中 一 个 深入 的 话题 : 滑动 冲突 。 相 信 开 发 
Android 的 人 都 会 有 这 种 体会 滑动 冲突 实在 是 太 坑 人 了 ， 本 来 从 网 上 
下 载 的 demo 运 行 得 好 好 的 ， 但 是 只 要 出 现 滑 动 冲 突 ，demo 束 无 法 正 营 
工作 了 。 那 么 滑动 冲突 是 如 何 产生 的 呢 ?” 其 实在 界面 中 只 要 内 外 两 层 同 
时 可 以 滑动 ， 这 个 时 候 束 会 产生 滑动 冲突 。 如 何 解 决 背 动 冲突 呢 ? 这 既 
古 一 件 困难 的 事 又 是 一 件 简单 的 事 ， 说 困难 是 因为 许多 开 及 者 面 对 请 动 
冲突 都 会 显得 束手无策 ， 交 简单 是 因为 滑动 神 突 的 解决 有 固定 的 套路 ， 
只 要 知道 了 这 个 固定 套路 问题 就 好 解决 了 。 本 市 是 View 体 系 的 核心 章 
市 ， 前 面 4 闻 均 是 为 本 节 服 务 的 ， 通 过 本 市 的 学 习 ， 滑 动 冲 突 将 不 再 是 
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3.5.1 fe WL oT Ry ee 


常见 的 背 动 冲突 场景 可 以 简单 分 为 如 下 三 种 (详情 请 参看 图 3- 
4) : 























场景 1 场景 2 


图 3-4 滑动 冲突 的 场景 
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先 说 场景 1， 主 要 是 将 ViewPager 和 Fragment 配 合 使 用 所 组 成 的 页 面 
滑动 效果 ， 主 流 应 用 几乎 都 会 使 用 这 个 效果 。 在 这 种 效果 中 ， 可 以 通过 
左右 滑动 来 切换 页 面 ， 而 每 个 页 面 内 部 往往 又 是 一 个 ListView。 本 来 这 
种 情况 下 是 有 滑动 冲突 的 ， 但 是 ViewPager 内 部 处 理 了 这 种 滑动 冲突 ， 
因此 采用 ViewPager 时 我 们 无 须 关 注 这 个 问题 ， 如 果 我 们 采用 的 不 是 
ViewPager 而 是 ScrollView 等 ， 那 就 必须 手动 处 理 滑动 冲突 了 ， 否 则 造成 
的 后 果 就 是 内 外 两 层 只 能 有 一 层 能 够 滑动 ， 这 是 因为 两 者 之 间 的 滑动 事 
件 有 冲突 。 除 了 这 种 典型 情况 外 ， 还 存在 其 他 情况 ， 比 如 外 部 上 下 滑 
动 、 内 部 左右 滑动 等 ， 但 是 它们 属于 同一 类 滑动 冲突 。 














再 说 场景 2， 这 种 情况 就 稍微 复杂 一 些 ， 当 内 外 两 层 都 在 同一 个 方 
加 可 以 请 动 的 时 候 ， 显 然 存在 逻辑 问题 。 因 为 当 手 指 开始 请 动 的 时 候 ， 
系统 无 法 知 着 用 户 到 撒 是 想 让 哪 一 层 滑动 ， 所 以 当 手 指 滑动 的 时 候 就 会 
出 现 问题 ， 要 么 只 有 一 层 能 滑动 ， 要 么 就 是 内 外 两 层 都 滑动 得 很 卡 顿 。 
在 实际 的 开发 中 ， 这 种 场景 主要 是 指 内 外 两 层 同 时 能 上 下 滑动 或 者 内 外 
两 层 同 时 能 左右 滑动 。 

















最 后 说 下 场景 3， 场 景 3 是 场景 1 和 场景 2 两 种 情况 的 伦 套 ， 因 此 场景 
3 的 滑动 冲突 看 起 来 就 更 加 复杂 了 。 比 如 在 许多 应 用 中 会 有 这 么 一 个 效 
果 : 内 层 有 一 个 场景 1 中 的 滑动 效果 ， 然 后 外 层 又 有 一 个 场景 2 中 的 滑动 
效果 。 具 体 说 就 是 ， 外 部 有 一 个 SlideMenu 效 果 ， 然 后 内 部 有 一 个 
ViewPager，ViewPager 的 每 一 个 页 面 中 又 是 一 个 ListView。 虽 然 说 场景 3 
的 滑动 冲突 看 起 来 更 复杂 ， 但 是 它 是 几 个 单一 的 滑动 冲突 的 车 加 ， 因 此 
只 需要 分 别处 理 内 层 和 中 层 、 中 层 和 外 层 之 间 的 滑动 冲突 即 可 ， 而 有 具体 














的 处 理 方法 其 实 是 和 场景 1、 场 景 2 相 同 的 。 








从 本 质 上 来 说 ， 这 三 种 请 动 冲突 场景 的 复杂 度 其 实 是 相同 的 ， 因 为 
它们 的 区 别 仅仅 是 滑动 荣 略 的 不 同 ， 至 于 解决 滑动 神 突 的 方法 ， 它 们 几 
个 是 通用 的 ， 在 3.5.2 市 中 将 会 详细 介绍 这 个 问题 。 


3.5.2 THER HI Ab FEKE WI 


一 般 来 说 ， 不 管 请 动 冲突 多 么 复杂 ， 它 都 有 既定 的 规则 ， 根 据 这 些 
规则 我 们 束 可 以 选择 合适 的 方法 去 处 理 。 











如 图 3-4 所 示 ， 对 于 场景 1， 它 的 处 理 规则 是 : 当 用 户 左 右 滑 动 时 ， 
需要 让 外 部 的 View 拦 截 点 击 事件 ， 当 用 户 上 下 滑动 时 ， 需 要 让 内 部 
View 拦 截 点 击 事件 。 这 个 时 候 我 们 就 可 以 根据 它们 的 特征 来 解决 滑动 冲 
突 ， 有 具体 来 说 是 : 根据 滑动 是 水 平滑 动 还 是 紧 直 滑动 来 判断 到 抵 由 谁 来 
拦截 事件 ， 如 图 3-5 所 示 ， 根 据 滑 动 过 程 中 两 个 点 之 间 的 坐标 就 可 以 得 
出 到 确 是 水 平滑 动 还 是 紧 直 滑动 。 如 何 根据 坐标 来 得 到 滑动 的 方 稀 呢 ? 
这 个 很 简单 ， 有 很 多 可 以 参考 ， 比 如 可 以 依据 请 动 路 径 和 水 平方 稀 所 形 
成 的 夹 角 ， 也 可 以 依据 水 平方 向 和 竖 直 方向 上 的 距离 差 来 判断 ， 某 些 特 
殊 时 候 还 可 以 依据 水 平和 竖 直 方 癌 的 速度 兰 来 做 判断 。 这 里 我 们 可 以 通 
过 水 平和 竖 直 方 同 的 距离 差 来 判断 ， 比 如 紧 直 方 回 滑动 的 距离 大 就 判断 
为 竖 直 滑动 ， 人 否则 判断 为 水 平滑 动 。 根 据 这 个 规则 就 可 以 进行 下 一 步 的 
解决 方法 制定 了 。 
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对 于 场景 2 来 说 ， 比 较 特 殊 ， 它 无 法 根据 背 动 的 角 肛 、 距 离 差 以 及 
速度 兰 来 做 判断 ， 但 是 这 个 时 候 一 般 都 能 在 业务 上 找到 突破 点 ， 比 如 业 
务 上 有 规定 : 当 处 于 茶 种 状态 时 需要 外 部 View 员 应 用 户 的 滑动 ， 而 处 于 
另外 一 种 状态 时 则 需要 内 部 View 来 啊 应 View 的 滑动 ， 根 据 这 种 业务 上 
的 需求 我 们 也 能 得 出 相应 的 处 理 规则 ， 有 了 处 理 规则 同样 可 以 进行 下 一 
步 处 理 。 这 种 场景 通过 文字 搬 述 可 能 比较 抽象 ， 在 下 一 市 会 通过 实际 的 
例子 来 演示 这 种 情况 的 解决 方案 ， 那 时 就 容易 理解 了 ， 这 里 先 有 这 个 概 
念 即 可 。 














对 于 场景 3 来 说 ， 它 的 滑动 规则 就 更 复杂 了 ， 和 场景 2 一 样 ， 它 也 无 
法 直接 根据 滑动 的 角度 、 距 离 关 以 及 速度 兰 来 做 判断 ， 同 样 还 是 只 能 从 
业务 上 找到 突破 点 ， 有 具体 方法 和 场景 2 一 样 ， 都 是 从 业务 的 需求 上 得 出 
相应 的 处 理 规则， 在 下 一 市 将 会 通过 实际 的 例子 来 演示 这 种 情况 的 解决 
方案 。 





3.5.3 JASNA AREJITA 
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景 ， 这 也 是 最 简单 、 最 典型 的 一 种 滑动 冲突 ， 因 为 它 的 滑动 规则 比较 简 
单 ， 不 管 多 复杂 的 滑动 名 突 ， 它 们 之 间 的 区 别 仅仅 是 滑动 规则 不 同 而 
己 。 抛 开 滑 动 规则 不 说， 我 们 需要 找到 一 种 不 依赖 具体 的 滑动 规则 的 通 
用 的 解决 方法 ， 在 这 里 ， 我 们 束 根 据 场景 1 的 情况 来 得 出 通用 的 解决 方 
案 ， 然 后 场景 2 和 场景 3 我 们 只 需要 修改 有 关 滑 动 规则 的 逻辑 即 可 。 






































上 面 说 过 ， 人 针对 场景 1 中 的 滑动 ， 我 们 可 以 根据 滑动 的 距离 差 来 进 
行 判断 ， 这 个 距离 差 就 是 所 谓 的 滑动 规则 。 如 果 用 ViewPager 去 实现 场 
景 1 中 的 效果 ， 我 们 不 需要 手动 处 理 滑 动 冲突 ， 因 为 ViewPager 已 经 帮 有 我 
们 做 了 ， 但 是 这 里 为 了 更 好 地 演示 滑动 冲突 的 解决 思想 ， 没 有 来 用 
ViewPager。 其 实在 滑动 过 程 中 得 到 滑动 的 角度 这 个 是 相当 简单 的 ， 但 
是 到 底 要 怎么 做 才能 将 点 击 事 件 交 给 合适 的 View 去 处 理 呢 ?这 时 就 要 用 
到 3.4 节 所 讲述 的 事件 分 发 机 制 了 。 针 对 滑动 冲突 ， 这 里 给 出 两 种 解决 
滑动 冲突 的 方式 : 外 部 拦截 法 和 内 部 拦截 法 。 








1. 外 部 拦截 法 


所 谓 外 部 拦截 法 是 指点 击 事情 都 先 经 过 父 容 堪 的 拦截 处 理 ， 如 果 父 
容器 需要 此 事件 就 拦截 ， 如 果 不 需 要 此 事件 就 不 拦截 ， 这 样 就 可 以 解决 
滑动 冲突 的 问题 ， 这 种 方法 比较 符合 点 击 事件 的 分 发 机 制 。 外 部 拦截 法 
需要 重 写 父 容 器 的 onInterceptTouchEvent 方 法 ， 在 内 部 做 相应 的 拦截 即 
可 ， 这 种 方法 的 伪 代 人 码 如 下 所 示 。 




















} 


ERR USA EE GE RA, EO NTA TPS, OR tee 
修改 父 容器 需要 当前 点 击 事件 这 个 条 件 即 可 ， 其 他 均 不 需 做 修改 并 且 也 
不 能 修改 。 这 里 对 上 述 代 码 再 描述 一 下 ， 在 onInterceptTouchEvent 方 法 
中 ， 首 先是 ACTION_DOWN 这 个 事件 ， 父 容器 必须 返回 false， 即 不 拦 
截 ACTION_DOWN 事 件 ， 这 是 因为 一 旦 父 容 器 拦截 了 
ACTION_DOWN， 那 么 后 续 的 ACTION_MOVE 和 ACTION_UP 事 件 都 会 
直接 交 由 父 容器 处 理 ， 这 个 时 候 事 件 没 法 再 传递 给 子 元 素 了 ; 其 次 是 
ACTION_MOVE 事 件 ， 这 个 事件 可 以 根据 需要 来 决定 是 人 否 拦 截 ， 如 果 
父 容器 需要 拦截 束 返 回 true， 否 则 返回 false; 最 后 是 ACTION_UP 事 件 ， 
这 里 必须 要 返回 false， 因 为 ACTION_UP 事 件 本 身 没 有 太 多 意义 。 




















考虑 一 种 情况 ， 假 设 事件 交 由 子 元 素 处 理 ， 如 果 父 容器 在 
ACTION_UP 时 返回 了 true， 束 会 导致 子 元 素 无 法 接收 到 ACTION_UP 事 
件 ， 这 个 时 候 子 元 素 中 的 onClick 事 件 就 无 法 触发 ， 但 是 父 容器 比较 特 
丈 ， 一 旦 它 开 始 拦截 任何 一 个 事件 ， 那 么 后 续 的 事件 都 会 交 给 它 来 处 
理 ， 而 ACTION_UP 作 为 最 后 一 个 事件 也 必定 可 以 传递 给 父 容 器 ， 即 便 
父 容器 的 onInterceptTouchEvent 方 法 在 ACTION_UP 时 返回 了 false。 














2. 内 部 拦截 法 


内 部 拦截 法 是 指 父 容器 不 拦截 任何 事件 ， 所 有 的 事件 都 传递 给 子 元 
素 ， 如 果子 元 素 需 要 此 事件 就 直接 消耗 掉 ， 人 否则 就 区 由 父 容器 进行 处 
理 ， 这 种 方法 和 Android 中 的 事件 分 发 机 制 不 一 致 ， 需 要 配合 
requestDisallowInterceptTouchEvent 方 法 才能 正常 工作 ， 使 用 起 来 较 外 部 
拦截 法 稍 显 复杂 。 它 的 伪 代 人 码 如 下 ， 我 们 需要 重 写 子 元 素 的 
dispatchTouchEvent 方 法 : 

















上 述 代 码 是 内 部 拦截 法 的 典型 代码 ， 当 面 对 不 同 的 滑动 策略 时 只 需 
要 修改 里 面 的 条 件 即 可 ， 其 他 不 需要 做 改动 而 且 也 不 能 有 改动 。 除 了 子 
元 素 需 要 做 处 理 以 外 ， 父 元 素 也 要 默认 拦截 除了 ACTION_DOWN 以 外 
的 其 他 事件 ， 这 样 当 子 元 素 调用 parent.requestDisal- 
lowInterceptTouchEvent(false) 方 法 时 ， 父 元 素 才 能 继续 拦截 所 需 的 事 
件 。 








为 什么 父 容器 不 能 拦截 ACTION_DOWN 事 件 呢 ? 那 是 因为 
ACTION_DOWN 事 件 并 不 受 FLAG_DISALLOW_INTERCEPT 这 个 标记 
位 的 控制 ， 所 以 一 旦 父 容器 拦截 ACTION_DOWN 事 件 ， 那 么 所 有 的 事 
件 都 无 法 传递 到 子 元 素 中 去 ， 这 样 内 部 拦截 就 无 法 起 作用 了 。 父 元 素 所 
做 的 修改 如 下 所 示 。 


public boolean onInterceptTouchEvent(MotionEvent event) { 
int action = event.getAction(); 
if (action == MotionEvent.ACTION_DOWN) { 
return false; 
} else { 


return true; 


} 


下 面 通 过 一 个 实例 来 分 别 介绍 这 两 种 方法 。 我 们 来 实现 一 个 类 似 于 
ViewPager 中 骸 套 ListView 的 效果 ， 为 了 制造 滑动 冲突 ， 我们 写 一 个 类 似 
于 ViewPager 的 控件 即 可 ， 名 字 就 叫 HorizontalScrollViewEx， 这 个 控件 
的 具体 实现 思想 会 在 第 4 章 进 行 详 细 介 绍 ， 这 里 只 讲述 滑动 冲突 的 部 


are 





为 了 实现 ViewPager 的 效果 ， 我 们 定义 了 一 个 类 似 于 水 平 的 
LinearLayout 的 东西 ， 只 不 过 它 可 以 水 平滑 动 ， 初 始 化 时 我 们 在 它 的 内 
部 琴 加 各 和 干 个 ListView， 这 样 一 来 ， 由 于 它 内 部 的 Listview 可 以 竖 直 清 
动 。 而 它 本 身 又 可 以 水 平滑 动 ， 因 此 一 个 典型 的 滑动 冲突 场景 就 出 现 
了 ， 并 且 这 种 冲突 属于 类 型 1 的 冲突 。 根 据 滑动 策略 ， 我 们 可 以 选择 水 
平和 竖 直 的 滑动 距离 差 来 解决 滑动 冲突 。 








首先 来 看 一 下 Activity 中 的 初始 化 代码 ， 如 下 所 示 。 


public class DemoActivity_1 extends Activity { 

private static final String TAG = "SecondActivity"; 

private HorizontalScrollViewEx mListContainer; 

@Override 

protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savediInstanceState) ; 
setContentView(R.layout.demo_1); 
Log.d(TAG, "onCreate"); 
initView(); 

} 

private void initView() { 
LayoutInflater inflater = getLayoutInflater(); 
mListContainer = (HorizontalScrollViewEx) findViewBy 
container); 
final int screenwidth = MyUtils.getScreenMetrics(thi 
final int screenHeight = MyUtils.getScreenMetrics(th 
Pixels; 


ror (ime a = 0p i & 8 Iam) i 


ViewGroup layout = (ViewGroup) inflater.inflate( 
R.layout.content_layout,mListContainer, f 

layout.getLayoutParams().width = screenWidth; 

TextView textView = (TextView) layout .findViewBy 

textView.setText("page " + (i + 1)); 

layout .setBackgroundColor(Color.rgb(255/(1i+1),25 

createList(layout); 


mListContainer .addView(layout ); 


} 


private void createList(ViewGroup layout) { 

ListView listView = (ListView) layout.findViewById(R 

ArrayList<String> datas = new ArrayList<String>()j; 

fOr (inet = Op al 50 a ee 

datas.add("name " + i); 

} 

ArrayAdapter<String> adapter = new ArrayAdapter<Stri 
R.layout.content_list_item,R.id.name, datas); 


listView.setAdapter (adapter); 


上 述 初始 化 代码 很 简单 ， 就 是 创建 了 3 个 ListView 并 且 把 ListView 加 
入 到 我 们 目 定 义 的 HorizontalScrollViewEx 中 ， 这 里 
HorizontalScrollViewEx 是 父 容器 ， 而 ListView 则 是 子 元 素 ， 这 里 束 不 再 
多 介绍 了 。 


首先 采用 外 部 拦截 法 来 解决 这 个 问题 ， 按 照 前 面 的 分 析 ， 我 们 只 需 
要 修改 父 容器 需要 拦截 事件 的 条 件 即 可 。 对 于 本 例 来 说 ， 父 容器 的 拦截 
条 件 就 是 滑动 过 程 中 水 平 距离 差 比 竖 直 距离 差 大 ， 在 这 种 情况 下 ， 父 容 
器 就 拦截 当前 点 击 事件 ， 根 据 这 一 条 件 进行 相应 修改 ， 修 改 后 的 
HorizontalScrollViewEx 的 onInterceptTouchEvent 方 法 如 下 所 示 。 





break; 
t 
case MotionEvent.ACTION_UP: { 


intercepted = false; 


break; 
t 
default: 
break; 
J 


Log.d(TAG, "intercepted=" + intercepted); 
mLastXIntercept = x; 

mLastYIntercept = y; 

return intercepted; 


} 


从 上 面 的 代码 来 看 ， 它 和 外 部 拦截 法 的 伪 代 码 的 差别 很 小 ， 只 是 把 
父 容器 的 拦截 条 件 换 成 了 具体 的 逻辑 。 在 滑动 过 程 中 ， 当 水 平方 同 的 距 
离 大 时 就 判断 为 水 平滑 动 ， 为 了 能 够 水 平滑 动 所 以 让 父 容器 拦截 事件 ; 
而 竖 直 距离 大 时 父 容器 就 不 拦截 事件 ， 于 是 事件 就 传递 给 了 ListView， 
所 以 ListView 也 能 上 下 请 动 ， 如 此 滑动 冲突 就 解 诀 了。 至 于 
mScroller.abortAnimation() 这 一 句 话 主 要 是 为 了 优化 滑动 体验 而 加 入 的 。 


考 碟 一 种 情况 ， 如 有 果 此 时 用 户 正 在 水 平滑 动 ， 但 是 在 水 平滑 动 停止 
之 前 如 果 用 户 再 迅速 进行 竖 直 滑动 ， 就 会 导致 界面 在 水 平方 网 无 法 滑动 
到 终点 从 而 处 于 一 种 中 间 状 态 。 为 了 避免 这 种 不 好 的 体验 ， 当 水 平方 问 
正在 滑动 时 ， 下 一 个 序列 的 点 击 事件 仍然 区 给 父 容 器 处 理 ， 这 样 水 平方 
器 融 不 会 停留 在 中 间 状 态 了 。 





下 面 是 HorizontalScrollViewEx 的 具体 实现 ， 只 展示 了 和 滑动 冲突 相 
关 的 代码 : 














scrollTo(mScroller.getCurrX(),mScroller.getCurry 


postInvalidate(); 





如 果 采 用 内 部 拦截 法 也 是 可 以 的 ， 按 照 前 面 对 内 部 拦截 法 的 分 析 ， 
我 们 只 需要 修改 ListView 的 dispatchTouchEvent 方 法 中 的 父 容器 的 拦截 还 
辑 ， 同 时 让 父 容器 拦截 ACTION_MOVE 和 ACTION_UP 事 件 即 可 。 为 了 
重 写 ListView 的 dispatchTouchEvent 方 法 ， 我 们 必须 自 定义 一 个 
ListView， 称 为 ListViewEx， 然 后 对 内 部 拦截 法 的 模板 代码 进行 修改 ， 
根据 需要 ，ListViewEx 的 实现 如 下 所 示 。 


public class ListViewEx extends ListView { 
private static final String TAG = "ListViewEx"; 
private HorizontalScrollViewEx2 mHorizontalScrollViewEx2 
// 分 别 记录 上 次 滑动 的 坐标 
private int mLastX = 0; 


private int mLastY = 0; 


@Override 

public boolean dispatchTouchEvent(MotionEvent event) { 
int x = (int) event.getXx(); 
int y = (int) event.getY(); 
switch (event.getAction()) { 


case MotionEvent.ACTION DOWN: { 


除了 上 面 对 ListView 所 做 的 修改 ， 我 们 还 需要 修改 
HorizontalScrollViewEx 的 onInte-rceptTouchEvent 方 法 ， 修 改 后 的 类 暂且 





叫 HorizontalScrollViewEx2， 其 onInterceptTouchEvent 方 法 如 下 所 示 。 


public boolean onInterceptTouchEvent(MotionEvent event) { 
int x = (int) event.getx(); 
int y = (int) event.getyY(); 
int action = event.getAction(); 
if (action == MotionEvent.ACTION_DOWN) { 
mLastX = x; 
mLastY = y; 
if (!mScroller.isFinished()) { 
mScroller.abortAnimation(); 
return true; 
Í 
return false; 
} else { 


return true; 


} 


上 面 的 代码 就 是 内 部 拦截 法 的 示例 ， 其 中 mScroller.abortAnimation() 
这 一 句 不 是 必须 的 ， 在 当前 这 种 情形 下 主要 是 为 了 优化 滑动 体验 。 从 实 
现 上 来 看 ， 内 部 拦截 法 的 操作 要 稍微 复杂 一 些 ， 因 此 推荐 采用 外 部 拦截 
法 来 解决 常见 的 滑动 冲突 。 








前 面 说 过 ， 只 要 我 们 根据 场景 1 的 情况 来 得 出 通用 的 解决 方案 ， 那 
么 对 于 场景 2 和 场景 3 来 说 我 们 只 需要 修改 相关 滑动 规则 的 馆 辑 即 可 ， 下 
面 我 们 就 来 演示 如 何 利用 场景 1 得 出 的 通用 的 解决 方案 来 解决 更 复杂 的 
请 动 名 突 。 这 里 只 详细 分 析 场 景 2 中 的 滑动 冲 突 ， 对 于 场景 3 中 的 县 加 型 
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决 每 层 之 间 的 滑动 冲突 即 可 ， 再 加 上 本 书 的 篇 幅 有 限 ， 这 里 就 不 对 场景 
3 进行 详细 分 析 了 。 




















对 于 场景 ?来 说 ， 它 的 解决 方法 和 场景 1 一 样 ， 只 是 滑动 规则 不 同 而 
己 ， 在 前 面 我 们 已 经 得 出 了 通用 的 解决 方案 ， 因 此 这 里 我 们 只 需要 蔡 换 
父 容 圳 的 拦截 规则 即 可 。 注 意 ， 这 里 不 再 演示 如 何 通过 内 部 拦截 法 来 解 
决 场景 2 中 的 滑动 补 突 ， 因 为 内 部 拦截 法 没有 外 部 拦截 法 简单 易 用 ， 所 
以 推 存 采 用 外 部 拦截 法 来 解决 疝 见 的 滑动 名 突 。 








下 面 通过 一 个 实际 的 例子 来 分 析 场 景 2， 首 先 我 们 提供 一 个 可 以 上 
下 滑动 的 父 容器 ， 这 里 就 叫 StickyLayout， 它 看 起 来 就 像 是 可 以 上 下 滑 
动 的 竖 直 的 LinearLayout， 然 后 在 它 的 内 部 分 别 放 一 个 Header 和 一 个 
ListView， 这 样 内 外 两 层 都 能 上 下 请 动 ， 于 是 就 形成 了 场景 2 中 的 滑动 
冲突 了 。 当 然 这 个 StickyLayout 是 有 清 动 规则 的 : 当 Header 显 示 时 或 者 
ListView 滑 动 到 顶部 时 ， 由 StickyLayout 拦 截 事件 ， 当 Header 隐 藏 时 ， 这 
要 分 情况 ， 如 果 ListView 已 经 滑动 到 顶部 并 且 当 前 手势 是 向 下 请 动 的 
话 ， 这 个 时 候 还 是 StickyLayout 拦 截 事 件 ， 其 他 情况 则 由 ListView 拦 截 事 
件 。 这 种 滑动 规则 看 起 来 有 点 复杂 ， 为 了 解决 它们 之 间 的 滑动 冲突 ， 我 
们 还 是 需要 重 写 父 容器 StickyLayout 的 onInterceptTouchEvent 方 法 ， 至 于 
ListView 则 不 用 做 任何 修改 ， 我 们 来 看 一 下 StickyLayout 的 具体 实现 ， 清 
动 冲突 相关 的 主要 代码 如 下 所 示 。 


























public class StickyLayout extends LinearLayout { 
private int mTouchSlop; 
// 分 别 记录 上 次 滑动 的 坐标 


private int mLastX = 0; 











从 上 面 的 代码 来 看 ， 这 个 StickyLayout 的 实现 有 点 复杂 ， 在 第 4 章 会 
详细 介绍 这 个 自 定义 View 的 实现 思想 ， 这 里 先 有 大 概 的 印象 即 可 。 下 面 
我 们 主要 看 它 的 onIntercept-TouchEvent 方 法 中 对 ACTION_MOVE 的 处 
理 ， 如 下 所 示 。 





} else if (mStatus == STATUS_EXPANDED && deltaY <= -mTouc 
intercepted = 1; 

} else if (mGiveUpTouchEventListener != null) { 
if (mGiveUpTouchEventListener .giveUpTouchEvent (ev 


intercepted = 1; 


break; 


我 们 来 分 机 上 面 这 段 代 码 的 逻辑 ， 这 里 的 父 容器 是 StickyLayout， 

子 元 素 是 ListView。 首 先 ， 当 事件 落 在 Header 上 面 时 父 容器 不 会 拦截 事 
件 ; 接着 ， 如 果 竖 直 距 离 莽 小 于 水 平 距离 差 ， 那 么 父 容器 也 不 会 拦截 事 
件 ;， 然 后 ， 当 Header 是 展开 状态 并 且 加 上 滑动 时 父 容器 拦截 事件 。 另 外 
一 种 情况 ， 当 ListView 滑 动 到 顶部 了 并 且 辐 下 滑动 时 ， 父 容器 也 会 拦截 
事件 ， 经 过 这 些 层 层 判断 就 可 以 达到 我 们 想 要 的 效果 了 。 夯 外 ， 
giveUpTouchEvent 是 一 个 接口 方法 ， 由 外 部 实现 ， 在 本 例 中 主要 是 用 来 
判断 ListView 征 否 滑动 到 顶部 ， 它 的 具体 实现 如 下 : 














public boolean giveUpTouchEvent(MotionEvent event) { 
if (expandableListView.getFirstVisiblePosition() == 0) { 
View view = expandableListView.getChildAt(0); 
if (view != null && view.getTop() => 0) { 


return true; 


} 


return false; 


} 





上 面 这 个 例子 比较 复杂 ， 需 要 读者 多 多 体会 其 中 的 写法 和 思想 。 到 
这 里 滑动 冲突 的 解决 方法 就 介绍 完毕 了 ， 人 至 于 场景 3 中 的 滑动 冲突 ， 利 
用 本 市 所 给 出 的 通用 的 方法 是 可 以 轻松 解决 的 ， 读 者 可 以 自己 练习 一 
下 。 在 第 4 章 会 介绍 View 的 底层 工作 原理 ， 并 且 会 介绍 如 何 写 出 一 个 好 
的 自 定 义 View。 同 时 ， 在 本 节 中 所 提 到 的 两 个 自 定 义 View: Horizontal- 
ScrollViewEx 和 StickyLayout 将 会 在 第 4 章 中 进行 详细 的 介绍 ， 它 们 的 完 
整 源 码 请 查看 本 书 所 提供 的 示例 代码 。 











第 4 草 View 的 工作 原理 


在 本 章 中 主要 介绍 两 方面 的 内 容 ， 首 先 介 绍 View 的 工作 原理 ， 接 关 
介绍 自 定 义 View 的 实现 方式 。 在 Android 的 知识 体系 中 ，View 扮 演 着 很 
重要 的 角色 ， 简 单 来 理解 ，View 是 Android 在 视觉 上 的 呈现 。 在 界面 上 
Android 提 供 了 一 套 GUI 库 ， 里 面 有 很 多 控件 ， 但 是 很 多 时 候 我 们 并 不 满 
中 于 系统 提供 的 控件 ， 因 为 这 样 就 意味 这 应 用 界面 的 同类 化 比较 严重 。 
那么 怎么 才能 做 出 与 众 不 同 的 效果 呢 ? 管 案 是 自 定义 View， 也 可 以 叫 自 
定义 控件 ， 通 过 自 定义 View 我 们 可 以 实现 各 种 五 花 八 门 的 效果 。 但 是 自 
定义 View 是 有 一 定 难度 的 ， 尤 其 是 复杂 的 自 定 义 View， 大 部 分 时 候 我 
们 仅仅 了 解 基本 控件 的 使 用 方法 是 无 法 做 出 复杂 的 自 定 义 控件 的 。 为 了 
更 好 地 自 定义 View， 还 需要 掌握 View 的 底层 工作 原理 ， 比 如 View 的 测 
量 流程 、 布 局 流程 以 及 绘制 流程 ， 掌 握 这 几 个 基本 流程 后 ， 我 们 就 对 
View 的 底层 更 加 了 解 ， 这 样 我 们 驶 可 以 做 出 一 个 比较 完善 的 自 定 义 


View. 

















除了 View 的 三 大 流程 以 外 ，View 和 常见 的 回调 方法 也 是 需要 熟练 掌 
所 的， 比如 构造 方法 、onAttach、onVisibilityChanged、onDetach 等 。 男 
外 对 于 一 些 具 有 滑动 效果 的 上 自 定 义 View， 我 们 还 需要 处 理 View 的 滑 
BN, WIFI BTS PS I m ZEA AE DY a 关于 滑动 和 滑动 
冲突 这 一 块 内 容 已 经 在 第 3 章 中 进行 了 全 面 介绍 。 自 定义 View 的 实现 看 
起 来 很 复杂 ， 实 际 上 说 简单 也 简单 。 Ba, 自 定 义 View 是 有 几 种 固 
定 类 型 的 ， 有 i 直接 继承 自 View 和 ViewGroup， 而 有 的 则 选择 继承 现 有 
的 系统 控件 ， 这 些 都 可 以 ， 关 键 是 要 选择 最 适合 当前 需要 的 方式 ， 选 对 








自 定义 View 的 实现 方式 可 以 起 到 事半功倍 的 效果 ， 下 面 就 围绕 着 这 些 话 
题 一 一 展开 。 


4.1 初 识 ViewRoot 和 DecorView 


在 正式 介绍 View 的 三 大 流程 之 前 ， 我 们 必须 先 介绍 一 些 基 本 概念 ， 
这 样 才能 更 好 地 理解 View 的 measure、layout 和 draw 过 程 ， 本 节 主 要 介绍 
ViewRoot 和 DecorView 的 概念 。 





ViewRoot 对 应 于 ViewRootImpl 类 ， 它 是 连接 WindowManager 和 
DecorView 的 纽带 ，View 的 三 大 流程 均 是 通过 ViewRoot 来 完成 的 。 在 
ActivityThread 中 ， 当 Activity 对 象 被 创建 完毕 后 ， 会 将 DecorView 添 加 到 
Window 中 ， 同 时 会 创 全 象 ， 并 将 ViewRootImpl 对 象 和 
DecorView 建 立 关 联 ， 这 个 过 程 可 参看 如 下 源码 : 


root = new ViewRootImpl(view.getContext(),display); 


root.setView( view, wparams, panelParentView) ; 


View 的 绘制 流程 是 从 ViewRoot 的 performTraversals 方 法 开始 的 ， 它 
经 过 measure、layout 和 draw 三 个 过 程 才 能 最 终 将 一 个 View 绘 制 出 来 ， 其 
中 measure 用 来 测量 View 的 宽 和 高 ，layout 用 来 确定 View 在 父 容 器 中 的 放 
置 位 置 ， 而 draw 则 负责 将 View 绘 制 在 屏幕 上 。 针 对 performTraversals 的 
大 致 流程 ， 可 用 流程 图 4-1 来 表示 。 





performMeasure measure onMeasure | | measure 
t 





performLayout | 

















如 图 4-1 所 示 ，performTraversals 会 依次 调用 performMeasure、 
performLayout 和 performDraw 三 个 方法 ， 这 三 个 方法 分 别 完成 顶级 View 
的 measure、layout 和 draw 这 三 大 流程 ， 其 中 在 performMeasure 中 会 调用 
measure 方 法 ， 在 measure 方 法 中 又 会 调用 onMeasure 方 法 ， 在 onMeasure 
方法 中 则 会 对 所 有 的 子 元 素 进行 measure 过 程 ， 这 个 时 候 measure 流 程 就 
从 父 容器 传递 到 子 元 素 中 了 ， 这 样 就 完成 了 一 次 measure 过 程 。 接 着 子 
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历 。 同 理 ，performLayout 和 performDraw 的 传递 流程 和 performMeasure 是 
类 似 的 ， 唯 一 不 同 的 是 ，performDraw 的 传递 过 程 是 在 draw 方 法 中 通过 
dispatchDraw 来 实现 的 ， 不 过 这 并 没有 本 质 区 别 。 





measure 过 程 决 定 了 View 的 宽 / 高 ，Measure 完 成 以 后 ， 可 以 通过 
getMeasuredWidth 和 getMeasuredHeight 方 法 来 获取 到 View 测 量 后 的 宽 / 
高 ， 在 几乎 所 有 的 情况 下 它 都 等 同 于 View 最 终 的 宽 / 高 ， 但 是 特殊 情况 








除外 ， 这 点 在 本 章 后 面 会 进行 说 明 。Layout 过 程 决 定 了 View 的 四 个 顶点 
的 华 标 和 实际 的 View 的 宽 / 高 ， 完 成 以 后 ， 可 以 通过 getTop、 

getBottom、 getLeft 和 getRight 来 拿 到 View 的 四 个 顶点 的 位 置 ， 并 可 以 通 
过 getWidth 和 getHeight 方 法 来 拿 到 View 的 最 终 宽 / 高 。Draw 过 程 则 决定 
了 View 的 显示 ， 只 有 draw 方 法 完成 以 后 View 的 内 容 才 能 呈现 在 屏幕 

Ree 


如 图 4-2 所 示 ，DecorView 作 为 项 级 View， 一 般 情况 下 它 内 部 会 包含 
一 个 竖 直 方 同 的 LinearLayout， 在 这 个 LinearLayout 里 面 有 上 下 两 个 部 分 
(具体 情况 和 Android 版 本 及 主题 有 关 ) ， 上 面 是 标题 栏 ， 下 面 是 内 容 
栏 。 在 Activity 中 我 们 通过 setContentView 所 设置 的 布局 文件 其 实 就 是 被 
加 到 内 容 栏 之 中 的 ， 而 内 容 栏 的 id 是 content， 因 此 可 以 理解 为 Activity 指 

定 布局 的 方法 不 叫 setview 而 叫 setContentView， 因 为 我 们 的 布局 的 确 加 
到 了 id 为 content 的 FrameLayout 中 。 如 何 得 到 content 呢 ? 可 以 这 样 : 
ViewGroup content= findViewByld (R.android.id.content)。 如 何 得 到 我 们 
设置 的 View 呢 ?可 以 这 样 : content.getChildAt(0)。 同 时 ， 通 过 源码 我 们 
可 以 知道 ，DecorView 其 实 是 一 个 FrameLayout，View 层 的 事件 都 先 经 过 
DecorView， 然 后 才 传 递 给 我 们 的 View。 


android.R.id.content 





图 4-2 AView: DecorView 的 结构 


4.2 理解 MeasureSpec 


为 了 更 好 地 理解 View 的 测量 过 程 ， 我 们 还 需要 理解 MeasureSpec。 
从 名 字 上 来 看 ，MeasureSpec 看 起 来 像 “ 测 量规 格 ? 或 者 “测量 说 明 书 ”， 不 
管 怎么 翻译 ， 它 看 起 来 都 好 像 是 或 多 或 少 地 决定 了 View 的 测量 过 程 。 通 
过 源码 可 以 发 现 ，MeasureSpec 的 确 参 与 了 View 的 measure 过 程 。 读 者 可 
能 有 疑问 ，MeasureSpec 是 干什么 的 呢 ? 确 切 来 说 ，MeasureSpec 在 很 大 
程度 上 决定 了 一 个 View 的 尺寸 规格 ， 之 所 以 说 是 很 大 程度 上 是 因为 这 个 
过 程 还 受 父 容器 的 影响 ， 因 为 父 容器 影响 View 的 MeasureSpec 的 创建 过 
程 。 在 测量 过 程 中 ， 系 统 会 将 View 的 LayoutParams 根 据 父 容器 所 施加 的 
规则 转换 成 对 应 的 MeasureSpec， 然 后 再 根据 这 个 measureSpec 来 测量 出 
View 的 宽 / 高 。 上 面 提 到 过 ， 这 里 的 宽 / 高 是 测量 宽 /高 ， 不 一 定 等 于 View 
的 最 终 宽 /高 。MeasureSpec 看 起 来 有 点 复杂 ， 其 实 它 的 实现 是 很 简单 
的 ， 下 面 会 详细 地 分 析 MeasureSpec。 




















4.2.1 MeasureSpec 


MeasureSpec 代 表 一 个 32 位 int 值 ， 高 2 位 代表 SpecMode， 低 30 位 代 
表 SpecSize，SpecMode 是 指 测量 模式 ， 而 SpecSize 是 指 在 茶 种 测量 模式 
下 的 规格 大 小 。 下 面 先 看 一 下 MeasureSpec 内 部 的 一 些 常 量 的 定义 ， 通 
过 下 面 的 代码 ， 应 该 不 难 理解 MeasureSpec 的 工作 原理 : 


private static final int MODE_SHIFT = 30; 
private static final int MODE_MASK = 0x3 << MODE_SHIFT; 


public static final int UNSPECIFIED = 0 << MODE_SHIFT; 


public static final int EXACTLY = 1 << MODE_SHIFT; 
public static final int AT_MOST = 2 << MODE_SHIFT; 
public static int makeMeasureSpec(int size,int mode) { 
if (sUseBrokenMakeMeasureSpec) { 
return size + mode; 
} else { 
return (size & ~MODE_MASK) | (mode & MODE_MASK); 


} 


public static int getMode(int measureSpec) { 
return (measureSpec & MODE_MASK); 

} 

public static int getSize(int measureSpec) { 


return (measureSpec & ~MODE_MASK); 


MeasureSpec 通 过 将 SpecMode 和 SpecSize 打 包 成 一 个 int 值 来 避免 过 
多 的 对 象 内 存 分 配 ， 为 了 方便 操作 ， 其 提供 了 打包 和 解 包 方 法 。 
SpecMode 和 SpecSize 也 是 一 个 int 值 ， 一 组 SpecMode 和 SpecSize 可 以 打包 
为 一 个 MeasureSpec， 而 一 个 MeasureSpec 可 以 通过 解 包 的 形式 来 得 出 其 
原始 的 SpecMode 和 SpecSize， 需 要 注意 的 是 这 里 提 到 的 MeasureSpec 是 
指 MeasureSpec 所 代表 的 int 值 ， 而 并 非 MeasureSpec 本 喘 。 





SpecMode 有 三 类 ， 每 一 类 都 表示 特殊 的 含义 ， 如 下 所 示 。 
UNSPECIFIED 


父 容器 不 对 View 有 任何 限制 ， 要 多 大 给 多 大 ， 这 种 情况 一 般 用 于 系 


统 内 部 ， 表 示 一 种 测量 的 状态 。 
EXACTLY 


父 容器 已 经 检测 出 View 所 需要 的 精确 大 小 ， 这 个 时 候 View 的 最 终 
大 小 就 是 SpecSize 所 指定 的 值 。 它 对 应 于 LayoutParams 中 的 match_parent 
和 具体 的 数值 这 两 种 模式 。 


AT_MOST 


父 容器 指定 了 一 个 可 用 大 小 即 SpecSize，View 的 大 小 不 能 大 于 这 个 
值 ， 有 具体 是 什么 值 要 看 不 同 View 的 具体 实现 。 它 对 应 于 LayoutParams 中 


的 wrap_content。 


-> 


4.2.2 MeasureSpec 和 LayoutParams 
的 对 应 关系 


上 面 提 到 ， 系 统 内 部 是 通过 MeasureSpec 来 进行 View 的 测量 ， 但 是 
正常 情况 下 我 们 使 用 View 指 定 MeasureSpec， 尽 管 如 此 ， 但 是 我 们 可 以 
给 View 设 置 LayoutParams。 在 View 测 量 的 时 候 ， 系 统 会 将 LayoutParams 
在 父 容 妖 的 约束 下 转换 成 对 应 的 MeasureSpec， 然 后 再 根据 这 个 
MeasureSpec 来 确定 View 测 量 后 的 宽 / 高 。 需 要 注意 的 是 ，MeasureSpec 
不 是 唯一 由 LayoutParams 决 定 的 ，LayoutParams 需 要 和 父 容器 一 起 才能 
决定 View 的 MeasureSpec， 从 而 进一步 决定 View 的 宽 / 高 。 另 外 ， 对 于 顶 
级 View〈 即 DecorView) 和 普通 View 来 说 ，MeasureSpec 的 转换 过 程 略 
有 不 同 。 对 于 DecorView， 其 MeasureSpec 由 窗口 的 尺寸 和 其 自身 的 
LayoutParams 来 共同 确定 ; 对 于 普通 View， 其 MeasureSpec 由 父 容器 的 


MeasureSpec 和 上 自身 的 LayoutParams 来 共同 决定 ，MeasureSpec 一 旦 确定 
后 ，onMeasure 中 就 可 以 确定 View 的 测量 宽 / 高 。 


对 于 DecorView 来 说 ， 在 ViewRootImpl 中 的 measureHierarchy 方 法 中 
有 如 下 一 段 代 码 ， 它 展示 了 DecorView 的 MeasureSpec 的 创建 过 程 ， 其 中 
desiredWindowWidth 和 desired-WindowHeight 是 屏幕 的 尺寸 : 


childwidthMeasureSpec = getRootMeasureSpec(desiredwindowwidth 
childHeightMeasureSpec = getRootMeasureSpec(desiredwindowHeig 
height); 


performMeasure(childwidthMeasureSpec, childHeightMeasureSpec ) ; 


接着 再 看 一 下 getRootMeasureSpec 方 法 的 实现 : 


private static int getRootMeasureSpec(int windowSize,int root 

int measureSpec; 

switch (rootDimension) { 

case ViewGroup.LayoutParams.MATCH_PARENT: 
// Window can't resize. Force root view to be win 
measureSpec = MeasureSpec.makeMeasureSpec (windowS 
break; 

case ViewGroup.LayoutParams.WRAP_CONTENT: 
// Window can resize. Set max size for root view. 
measureSpec = MeasureSpec.makeMeasureSpec (windowS 
break; 

default: 
// Window wants to be an exact size. Force root v 


measureSpec = MeasureSpec.makeMeasureSpec(rootDim 


break; 


} 


return measureSpec; 


通过 上 述 代 码 ，DecorView 的 MeasureSpec 的 产生 过 程 就 很 明确 了 ， 
体 来 说 其 遵守 如 下 规则 ， 根 据 它 的 LayoutParams 中 的 宽 / 高 的 参数 来 划 


at 





2 


/ 


e LayoutParams.:MATCH PARENT: 精确 模式 ， 大 小 就 是 窗口 的 大 


小 ; 





e LayoutParams.WRAP_CONTENT: 最 大 模式 ， 大 小 不 定 ， 但 是 不 能 
超过 窗口 的 大 小 ; 

。 固定 大 小 《比如 100dp) : 精确 模式 ， 大 小 为 LayoutParams 中 指定 
IKK 





对 于 普通 View 来 说 ， 这 里 是 指 我 们 布局 中 的 View，View 的 measure 
过 程 由 ViewGroup 传 递 而 来 ， 先 看 一 下 ViewGroup 的 
measureChildWithMargins 方 法 : 


protected void measureChildwithMargins(View child, 
int parentWidthMeasureSpec, int widthUsed, 
int parentHeightMeasureSpec,int heightUsed) { 
final MarginLayoutParams lp = (MarginLayoutParams) child. 
final int childWidthMeasureSpec = getChildMeasureSpec (par 
+ widthUsed,1p.width); 
final int childHeightMeasureSpec = getChildMeasureSpec(pa 


+ heightUsed,1lp.height); 


child.measure(childWidthMeasureSpec, childHeightMeasureSpe 


上 述 方法 会 对 子 元 素 进 行 measure， 在 调用 子 元 素 的 measure 方 法 之 
前 会 先 通过 getChildMeasureSpec 方 法 来 得 到 子 元 素 的 MeasureSpec。 从 
代码 来 看 ， 很 显然 ， 子 元 素 的 MeasureSpec 的 创建 与 父 容器 的 
MeasureSpec 和 子 元 素 本 身 的 LayoutParams 有 关 ， 此 外 还 和 View 的 margin 
及 padding 有 关 ， 有 具体 情况 可 以 看 一 下 ViewGroup 的 getChildMeasureSpec 
方法 ， 如 下 所 示 。 





public static int getChildMeasureSpec(int spec,int padding, in 
int specMode = MeasureSpec.getMode(spec); 
int specSize = MeasureSpec.getSize(spec); 
int size = Math.max(0,SpecSize -padding); 
int resultSize = 0; 
int resultMode = 0; 
switch (specMode) { 
// Parent has imposed an exact size on us 
case MeasureSpec.EXACTLY: 
if (childDimension => 0) { 
resultSize = childDimension; 
resultMode = MeasureSpec.EXACTLY; 
} else if (childDimension == LayoutParams.MATCH_P 
// Child wants to be our size. So be it. 
resultSize = size; 
resultMode = MeasureSpec.EXACTLY; 


} else if (childDimension == LayoutParams.WRAP_CO 





// Child wants a specific size... let him 
resultSize = childDimension; 
resultMode = MeasureSpec.EXACTLY; 

} else if (childDimension == LayoutParams.MATCH_P 
// Child wants to be our size... find out 
// be 
resultSize = 0; 
resultMode = MeasureSpec.UNSPECIFIED; 

} else if (childDimension == LayoutParams.WRAP_CO 
// Child wants to determine its own size. 
// big it should be 
resultSize = 0; 


resultMode = MeasureSpec.UNSPECIFIED; 


break; 


return MeasureSpec.makeMeasureSpec(resultSize, resultMode ) 





上 述 方法 不 难 理解 ， 它 的 主要 作用 是 根据 父 容器 的 MeasureSpec 同 
时 结合 View 本 身 的 LayoutParams 来 确定 子 元 素 的 MeasureSpec， 参 数 中 
的 padding 是 指 父 容器 中 己 占 用 的 空间 大 小 ， 因 此 子 元 素 可 用 的 大 小 为 
父 容器 的 尺寸 减 去 padding， 具 体 代码 如 下 所 示 。 








int specSize = MeasureSpec.getSize(spec); 


int size = Math.max(0,specSize -padding); 


getChildMeasureSpec 清 楚 展 示 了 普通 View 的 MeasureSpec 的 创建 规 


则 ， 为 了 更 清晰 地 理解 getChildMeasureSpec 的 逻辑 ， 这 里 提供 一 个 表 ， 
表 中 对 getChildMeasureSpec 的 工作 原理 进行 了 梳理 ， 请 看 表 4-1。 注 意 ， 
表 中 的 parentSize 是 指 父 容器 中 目前 可 使 用 的 大 小 。 


表 4-1 普通 View 的 MeasureSpec 的 创建 规则 


EXACTLY AT MOST UNSPECIFIED 








EXACTLY EXACTLY EXACTLY 
childSize childSize childSize 





EXACTLY AT _ MOST UNSPECIFIED 
parentSize parentSize 0 





AT MOST AT MOST UNSPECIFIED 











parentSize parentSize 0 





针对 表 4-1， 这 里 再 做 一 下 说 明 。 前 面 已 经 提 到 ， 对 于 普通 View， 
其 MeasureSpec 由 父 容器 的 MeasureSpec 和 自身 的 LayoutParams 来 共同 决 
定 ， 那 么 针对 不 同 的 父 容器 和 View 本 号 不 同 的 LayoutParams，View 就 可 
以 有 多 种 MeasureSpec。 这 里 简单 说 一 下 ， 当 View 采 用 固定 宽 / 高 的 时 
候 ， 不 管 父 容器 的 MeasureSpec 是 什么 ，View 的 MeasureSpec 都 是 精确 模 
式 并 且 其 大 小 遵循 Layoutparams 中 的 大 小 。 当 View 的 宽 / 高 是 
match_parent 时 ， 如 果 父 容器 的 模式 是 精准 模式 ， 那 么 View 也 是 精准 模 
式 并 且 其 大 小 是 父 容器 的 剩余 空间 ; 如 果 父 容器 是 最 大 模式 ， 那 么 View 
也 是 最 大 模式 并 且 其 大 小 不 会 超过 父 容 喜 的 剩余 空间 。 当 View 的 宽 / 高 
是 wrap_content 时 ， 不 管 父 容 器 的 模式 是 精准 还 是 最 大 化 ，View 的 模式 
总 是 最 大 化 并 且 大 小 不 能 超过 父 容器 的 剩余 空间 。 可 能 读者 会 发 现 ， 在 
我 们 的 分 析 中 漏 摊 了 UNSPECIFIED 模 式 ， 那 是 因为 这 个 模式 主要 用 于 
系统 内 部 多 次 Measure 的 情形 ， 一 般 来 说 ， 我 们 不 需要 关注 此 模式 。 


通过 表 4-1 可 以 看 出 ， 只 要 提供 父 容器 的 MeasureSpec 和 子 元 素 的 
LayoutParams， 就 可 以 快速 地 确定 出 子 元 素 的 MeasureSpec 了 ， 有 了 
MeasureSpec 就 可 以 进一步 确定 出 子 元 素 测 量 后 的 大 小 了 。 需 要 说 明 的 





是 ， 表 4-1 并 非 是 什么 经 验 总 结 ， 它 只 是 getChildMeasureSpec 这 个 方法 以 
表格 的 方式 呈现 出 来 而 已 。 


4.3 ”View 的 工作 流程 


vy 


View 的 工作 流程 主要 是 指 measure、layout、draw 这 三 大 流程 ， 即 测 
量 、 布 局 和 绘制 ， 其 中 measure 确 定 View 的 测量 宽 / 高 ，layout 确 定 View 
的 最 终 宽 /高 和 四 个 顶点 的 位 置 ， 而 draw 则 将 View 绘 制 到 屏幕 上 。 


4.3.1 measure 过 程 











measure 过 程 要 分 情况 来 看 ， 如 果 只 是 一 个 原始 的 View， 那 么 通过 
measure 方 法 就 完成 了 其 测量 过 程 ， 如 果 是 一 个 ViewGroup， 除 了 完成 自 
己 的 测量 过 程 外 ， 还 会 志 历 去 调用 所 有 子 元 素 的 measure 方 法 ， 各 个 子 
元 素 再 递归 去 执行 这 个 流程 ， 下 面 针 对 这 两 种 情况 分 别 讨论 。 


口 


1. View 的 measure 过 程 


View 的 measure 过 程 由 其 measure 方 法 来 完成 ，measure 方 法 是 一 个 
final 类 型 的 方法 ， 这 意味 着 子 类 不 能 重 写 此 方法 ， 在 View 的 measure 方 
法 中 会 去 调用 View 的 onMeasure 方 法 ， 因 此 只 需要 看 onMeasure 的 实现 即 
可 ，View 的 onMeasure 方 法 如 下 所 示 。 








protected void onMeasure(int widthMeasureSpec, int heightMeasu 


setMeasuredDimension(getDefaultSize(getSuggestedMinimumwWi 


} 


上 述 代 码 很 简洁 ， 但 是 简洁 并 不 代表 简单 ，setMeasuredDimension 
方法 会 设置 View 宽 /高 的 测量 值 ， 因 此 我 们 只 需要 看 getDefaultSize 这 个 


方法 即 可 : 


public static int getDefaultSize(int size,int measureSpec) { 
int result = size; 
int specMode = MeasureSpec.getMode(measureSpec ) ; 
int specSize = MeasureSpec.getSize(measureSpec) ; 
switch (specMode) { 
case MeasureSpec.UNSPECIFIED: 
result = size; 
break; 
case MeasureSpec.AT_MOST: 
case MeasureSpec.EXACTLY: 
result = specSize; 
break; 


} 


return result; 


可 以 看 出 ，getDefaultSize 这 个 方法 的 逻辑 很 简单 ， 对 于 我 们 来 说 ， 
我 们 只 需要 看 AT_MOST 和 .EXACTLY 这 两 种 情况 。 简 单 地 理解 ， 其 实 
getDefaultSize 返 回 的 大 小 惑 是 measureSpec 中 的 specSize， 而 这 个 
specSize 就 是 View 测 量 后 的 大 小 ， 这 里 多 次 提 到 测量 后 的 大 小 ， 是 因为 
View 最 终 的 大 小 是 在 layout 阶 段 确定 的 ， 所 以 这 里 必须 要 加 以 区 分 ， 但 
是 几乎 所 有 情况 下 View 的 测量 大 小 和 最 终 大 小 是 相等 的 。 














至 于 UNSPECIFIED 这 种 情况 ， 一 般 用 于 系统 内 部 的 测量 过 程 ， 在 
这 种 情况 下 ，View 的 大 小 为 getDefaultSize 的 第 一 个 参数 size， 即 宽 / 高 分 
别 为 getSuggestedMinimumWidth 和 getSuggestedMinimumHeight 这 两 个 方 


法 的 返回 值 ， 看 一 下 它们 的 源码 : 


protected int getSuggestedMinimumwidth() { 


return (mBackground == null) ? mMinWidth : max(mMinWidth, 


} 
protected int getSuggestedMinimumHeight() { 


return (mBackground == null) ? mMinHeight : max(mMinHeigh 


里 只 分 析 getSuggestedMinimumWidth 方 法 的 实现 ， 
本 蕊 的 实现 原理 是 一 样 的 。 从 
getSuggestedMinimumWidth 的 代码 可 以 看 出 ， 如 果 View 没 有 设置 背景 ， 
那么 View 的 宽度 为 mMinWidth， 而 mMinWidth 对 应 于 android:minWidth 
这 个 属性 所 指定 的 值 ， 因 此 View 的 宽度 即 为 android:minWidth 属 性 所 指 
定 的 值 。 这 个 属性 如 果 不 指定 ， 那 么 mMinWidth 则 默认 为 0， 如 果 View 
指定 了 背景 ， 则 View 的 宽度 为 
max(mMinWidth,mBackground.getMinimumWidth())。mMinWidth 的 含义 





我 们 已 经 知道 了 ， 那 么 mBackground.getMinimumWidth0) 是 什么 呢 ? 我 
们 看 一 下 Drawable 的 getMinimumWidth 方 法 ， 如 下 所 示 。 


public int getMinimumWidth() { 
final int intrinsicWidth = getIntrinsicWidth(); 


return intrinsicWidth > 0 ? intrinsicWidth : 0; 


| 以 看 出 ，getMinimumWidth 返 回 的 就 是 Drawable 的 原始 宽度 ， 前 
提 是 这 个 Drawable 有 原始 宽度 ， 否 则 就 返回 0。 那 么 Drawable 在 什么 情 
况 下 有 原始 宽度 呢 ? 这 里 先 举 个 例子 说 明 一 下 ，ShapeDrawable 无 原始 


这 里 再 总 结 一 下 getSuggestedMinimumwWidth 的 逻辑 : 如 果 View 没 有 
设置 背景 ， 那 么 返回 android:minWidth 这 个 属性 所 指定 的 值 ， 这 个 值 可 
以 为 0;， 如 果 View 设 置 了 背景 ， 则 返回 android:minWidth 和 背景 的 最 小 宽 
度 这 两 者 中 的 最 大 值 ，getSuggestedMinimumWidth 和 
getSuggestedMinimumHeight 的 返回 值 就 是 View 在 UNSPECIFIED 情 况 下 


的 测量 宽 / 高 。 








从 getDefaultSize 方 法 的 实现 来 看 ，View 的 宽 / 高 由 specSize 决 定 ， 所 
以 我 们 可 以 得 出 如 下 结论 : 直接 继承 View 的 自 定义 控件 需要 重 写 
onMeasure 方 法 并 设置 wrap_content 时 的 自身 大 小 ， 否 则 在 布局 中 使 用 
wrap_content 就 相当 于 使 用 match_parent。 为 什么 呢 ? 这 个 原因 需要 结合 
上 述 代 码 和 表 4-1 才 能 更 好 地 理解 。 从 上 述 代 码 中 我 们 知道 ， 如 果 View 
在 布局 中 使 用 wrap_content， 那 么 它 的 specMode 是 AT_MOST 模 式 ， 在 这 
种 模式 下 ， 它 的 宽 / 高 等 于 specSize; 查 表 4-1 可 知 ， 这 种 情况 下 View 的 
specSize 是 parentSize， 而 parentSize 是 父 容 器 中 目前 可 以 使 用 的 大 小 ， 也 
就 是 父 容器 当前 剩余 的 空间 大 小 。 很 显然 ，View 的 宽 / 高 束 等 于 父 容器 
当前 剩余 的 空间 大 小 ， 这 种 效果 和 在 布局 中 使 用 match_parent 完 全 一 
致 。 如 何 解决 这 个 问题 呢 ? 也 很 简单 ， 代 码 如 下 所 示 。 








protected void onMeasure(int widthMeasureSpec, int heightMeasu 
super .onMeasure(widthMeasureSpec, heightMeasureSpec ) ; 
int widthSpecMode = MeasureSpec.getMode(widthMeasureSpec ) 
int widthSpecSize = MeasureSpec.getSize(widthMeasureSpec ) 
int heightSpecMode = MeasureSpec.getMode(heightMeasureSpe 


int heightSpecSize = MeasureSpec.getSize(heightMeasureSpe 


if (widthSpecMode == MeasureSpec.AT_MOST && heightSpecMod 
setMeasuredDimension(mwWidth, mHeight ); 

} else if (widthSpecMode == MeasureSpec.AT_MOST) { 
setMeasuredDimension(mWidth, heightSpecSize) ; 

} else if (heightSpecMode == MeasureSpec.AT_MOST) { 


setMeasuredDimension(widthSpecSize, mHeight ); 


在 上 面 的 代码 中 ， 我 们 只 需要 给 View 指 定 一 个 默认 的 内 部 宽 / 高 
(mWidth#llmHeight) ， 并 在 wrap_content 时 设置 此 宽 / 高 即 可 。 对 于 非 
wrap_content 情 形 ， 我 们 沿用 系统 的 测量 值 即 可 ， 至 于 这 个 默认 的 内 部 
宽 / 高 的 大 小 如 何 指定 ， 这 个 没有 固定 的 依据 ， 根 据 需要 灵活 指定 
可 。 如 果 查 看 TextView、ImageView 等 的 源码 就 可 以 知道 ， 针 对 


wrap_content 情 形 ， 它 们 的 onMeasure 方 法 均 做 了 特殊 处 理 ， 读 者 可 以 自 
行 但 看 它们 的 源码 。 








2. ViewGroup 的 measure 过 程 


对 于 ViewGroup 来 说 ， 除 了 完成 自己 的 measure 过 程 以 外 ， vee A 
去 调用 所 有 子 元 素 的 measure 方 法 ， 各 个 子 元 素 再 递归 去 执行 这 个 过 
en 


的 onMeasure 方 法 ， 但 是 它 提供 了 一 个 叫 measureChildren 的 方法 ， 如 下 
所 示 。 


protected void measureChildren(int widthMeasureSpec, int heigh 
final int size = mChildrenCount; 


final View[] children = mChildren; 


fOr (Ant t=O aL S SASA rl 
final View child = children[i]; 
if ((child.mViewFlags & VISIBILITY_MASK) != GONE) 


measureChild(child, widthMeasureSpec, heigh 


从 上 述 代 码 来 看 ，ViewGroup 在 measure 时 ， 会 对 每 一 个 子 元 素 进行 
measure，measureChild 这 个 方法 的 实现 也 很 好 理解 ， 如 下 所 示 。 


protected void measureChild(View child,int parentwidthMeasure 
int parentHeightMeasureSpec) { 
final LayoutParams lp = child.getLayoutParams(); 
final int childWidthMeasureSpec = getChildMeasureSpec (par 
mPaddingLeft + mPaddingRight, 1p.width); 
final int childHeightMeasureSpec = getChildMeasureSpec(pa 
mPaddingTop + mPaddingBottom, lp.height); 


child.measure(childWidthMeasureSpec, childHeightMeasureSpe 


很 显然 ，measureChild 的 思想 就 是 取出 子 元 素 的 LayoutParams， 然 
后 再 通过 getChildMeasureSpec 来 创建 子 元 素 的 MeasureSpec， 接 着 将 
MeasureSpec 直 接 传递 给 View 的 measure 方 法 来 进行 测量 。 
getChildMeasureSpec 的 工作 过 程 已 经 在 上 面 进 行 了 详细 分 析 ， 通 过 表 4-1 
可 以 更 清楚 地 了 解 它 的 逻辑 。 


我 们 知道 ，ViewGroup 并 没有 定义 其 测量 的 具体 过 程 ， 这 是 因为 





ViewGroup 是 一 个 抽象 类 ， 其 测量 过 程 的 onMeasure 方 法 需要 各 个 子 类 去 
具体 实现 ， 比 如 LinearLayout、RelativeLayout 等 ， 为 什么 ViewGroup 不 
(View 一 样 对 其 onMeasure 方 法 做 统 一 的 实现 呢 ? 那 是 因为 不 同 的 
ViewGroup 子 类 有 不 同 的 布局 特性 ， 这 导致 它们 的 测量 细 市 各 不 相同 ， 
比如 LinearLayout 和 RelativeLayout 这 两 者 的 布局 特性 显然 不 同 ， 因 此 
ViewGroup 无 法 做 统一 实现 。 下 面 就 通过 LinearLayout 的 onMeasure 方 法 
来 分 析 ViewGroup 的 measure 过 程 ， 其 他 Layout 类 型 读者 可 以 自行 分 析 。 





首先 来 看 LinearLayout 的 onMeasure 方 法 ， 如 下 所 示 。 


protected void onMeasure(int widthMeasureSpec, int heightMeasu 
if (mOrientation == VERTICAL) { 
measureVertical(widthMeasureSpec, heightMeasureSpe 
} else { 


measureHorizontal(widthMeasureSpec, heightMeasureS 





上 述 代码 很 简单 ， 我 们 选择 一 个 来 看 一 下 ， 比 如 选择 查看 竖 直 布局 
的 LinearLayout 的 测量 过 程 ， 即 measureVertical 方 法 ，measureVertical 的 
VANS COBO, PI ABR AMIE, BABS: 


// See how tall everyone is. Also remember max width. 
for (int i = 0; i < count; ++i) { 


final View child = getVirtualChildAt(i); 


// Determine how big this child would like to be. If this 


// previous children have given a weight,then we allow it 


// use all available space (and we will shrink things lat 

// if needed). 

measureChildBeforeLayout ( 
child, i1,widthMeasureSpec,0,heightMeasureSpec, 
totalWeight == 0 ? mTotalLength : 0); 

if (oldHeight != Integer.MIN_VALUE) { 

lp.height = oldHeight; 

Í 

final int childHeight = child.getMeasuredHeight(); 

final int totalLength = mTotalLength; 

mTotalLength=Math.max(totalLength, totalLength+childHeight 
lp.bottomMargin + getNextLocationOffset(child) 





NM EMS EIS AT A at, ARR SI TGR IPT BEL FC RT 
measureChild-BeforeLayout 方 法 ， 这 个 方法 内 部 会 调用 子 元 素 的 measure 
方法 ， 这 样 各 个 子 元 素 束 开始 依次 进入 measure 过 程 ， 并 且 系 统 会 通过 
mTotalLength 这 个 变量 来 存储 LinearLayout 在 竖 直 方 同 的 初步 高 度 。 每 测 
量 一 个 子 元 素 ，mTotalLength 就 会 增加 ， 增 加 的 部 分 主要 包括 了 子 元 素 
的 高 度 以 及 子 元 素 在 竖 直 方向 上 的 margin 等 。 当 子 元 素 测量 完毕 后 ， 
LinearLayout 会 测量 自己 的 大 小 ， 源 码 如 下 所 示 。 











// Add in our padding 
mTotalLength += mPaddingTop + mPaddingBottom; 
int heightSize = mTotalLength; 
// Check against our minimum height 


heightSize = Math.max(heightSize, getSuggestedMinimumHeight ( ) ) 


// Reconcile our calculated size with the heightMeasureSpec 
int heightSizeAndState=resolveSizeAndState(heightSize, heightM 
0); 

heightSize = heightSizeAndState & MEASURED_SIZE_MASK; 


setMeasuredDimension(resolveSizeAndState(maxwidth, widthMeasur 
childState), 
heightSizeAndState) ; 








这 里 对 上 述 代码 进行 说 明 ， 当 子 元 素 测量 完毕 后 ，LinearLayonut 会 
根据 子 元 素 的 情况 来 测量 自己 的 大 小 。 针 对 竖 直 的 LinearLayout 而 言 ， 
它 在 水 平方 加 的 测量 过 程 遵循 View 的 测量 过 程 ， 在 竖 直方 癌 的 测量 过 程 
则 和 View 有 所 人 不同。 具体 来 说 是 指 ， 如 果 它 的 布局 中 高 度 采 用 的 是 
match_parent 或 者 具体 数值 ， 那 么 它 的 测量 过 程 和 View 一 致 ， 即 高 度 为 
specSize; 如 果 它 的 布局 中 高 度 采 用 的 是 wrap_content， 那 么 它 的 高 度 是 
所 有 子 元 素 所 占用 的 高 上 度 总 和 ， 但 是 仍然 不 能 超过 它 的 父 容 器 的 剩余 空 
间 ， 当 然 它 的 最 终 高 度 还 需要 考虑 其 在 竖 直 方向 的 padding， 这 个 过 程 
可 以 进一步 参看 如 下 源码 : 



































public static int resolveSizeAndState(int size,int measureSpe 
childMeasuredState) { 

int result = size; 

int specMode = MeasureSpec.getMode(measureSpec) ; 

int specSize = MeasureSpec.getSize(measureSpec ) ; 

Switch (specMode) { 

case MeasureSpec.UNSPECIFIED: 


result = size; 


break; 
case MeasureSpec.AT_MOST: 
ithe Specsi7e = Esc 
result = specSize | MEASURED _STATE_TOO_SM 
} else { 
result = size; 
} 
break; 
case MeasureSpec.EXACTLY: 
result = specSize; 
break; 
} 
return result | (childMeasuredState&MEASURED_STATE_MASK ) ; 


Ww 





View 的 measure 过 程 是 三 大 流程 中 最 复杂 的 一 个 ，measure 完 成 以 
后 ， 通 过 getMeasured-Width/Height 方 法 就 可 以 正确 地 获取 到 View 的 测量 


> 


/高 。 需 要 注意 的 是 ， 在 某 些 极端 情况 下 ， 系 统 可 能 需要 多 次 measure 
才能 确定 最 终 的 测量 宽 / 高 ， 在 这 种 情形 下 ， 在 onMeasure 方 法 中 拿 到 的 
测量 宽 / 高 很 可 能 是 不 准确 的 。 一 个 比较 好 的 习惯 是 在 onLayout 方 法 中 去 
获取 View 的 测量 宽 / 高 或 者 最 终 宽 / 高 。 
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上 面 已 经 对 View 的 measure 过 程 进行 了 详细 的 分 析 ， 现 在 考虑 一 种 
情况 ， 比 如 我 们 想 在 Activity 已 启动 的 时 候 就 做 一 件 任务 ， 但 是 这 一 件 
任务 需要 获取 某 个 View 的 宽 / 高 。 读 者 可 能 会 说 ， 这 很 简单 啊 ， 在 
onCreate 或 者 onResume 里 面 去 获取 这 个 View 的 宽 / 蜗 不 就 行 了 ? 读者 可 
以 自行 斌 一下， 实际 上 在 onCreate、onStart、onResume 中 均 无 法 正确 得 








到 某 个 View 的 宽 / 高 信息 ， 这 是 因为 View 的 measure 过 程 和 Activity 的 生 
命 周期 方法 不 是 同步 执行 的 ， 因 此 无 法 保证 Activity 执 行 了 onCreate、 
onStart、onResume 时 某 个 View 已 经 测量 完毕 了 ， 如 果 View 还 没有 测量 
完毕 ， 那 么 获得 的 宽 / 高 就 是 (。 有 没有 什么 方法 能 解决 这 个 问题 呢 ? 答 


案 是 有 的 ， 这 里 给 出 四 种 方法 来 解决 这 个 问题 : 














(1) Activity/View#onWindowFocusChanged. 


onWindowFocusChanged 这 个 方法 的 含义 是 : View 已 经 初始 化 完毕 
了 ， 宽 /高 已 经 准备 好 了 ， 这 个 时 候 去 获取 宽 / 高 是 没 问 题 的 。 需 要 注意 
的 是 ，onWindowFocusChanged 会 被 调用 多 次 ， 当 Activity 的 窗口 得 到 焦 
点 和 失去 焦点 时 均 会 被 调用 一 次 。 具 体 来 说 ， 当 Activity 继 续 执 行 和 和 暂 
停 执 行 时 ，onWindowFocusChanged 均 会 被 调用 ， 如 果 频 繁 地 进行 
onResume 和 onPause， 那 么 onWindowFocusChanged 也 会 被 频繁 地 调用 。 


典型 代码 如 下 : 


public void onWindowFocusChanged(boolean hasFocus) { 
super .onWindowFocusChanged(hasFocus) ; 


if (hasFocus) { 


int width = view.getMeasuredwidth()j; 


int height = view.getMeasuredHeight(); 


(2) view.post(runnable). 
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(3) ViewTreeObserver. 


使 用 ViewTreeObserver 的 众多 回调 可 以 完成 这 个 功能 ， 比 如 使 用 
OnGlobalLayoutListener 这 个 接口 ， 当 View 树 的 状态 发 生 改 变 或 者 View 
树 内 部 的 View 的 可 见 性 发 现 改变 时 ，onGlobalLayout 方 法 将 被 回调 ， 
此 这 是 获取 View 的 宽 /高 一 个 很 好 的 时 机 。 需 要 注意 的 是 ， 伴 随 着 View 
树 的 状态 改变 等 ，onGlobalLayout 会 被 调用 多 次 。— 典 型 代码 如 下 : 





view.getViewTreeObserver().removeGlobalOn 
int width = view.getMeasuredwidth(); 


int height = view.getMeasuredHeight(); 


Ww 


(4) view.measure(int widthMeasureSpec,int heightMeasureSpec). 





通过 手动 对 View 进 行 measure 来 得 到 View 的 宽 / 高 。 这 种 方法 比较 复 
这 里 要 分 情况 处 理 ， 根 据 View 的 LayoutParams 来 分 : 


as 


match_parent 





直接 放弃 ， 无 法 measure 出 具体 的 宽 / 高 。 原 因 很 简单 ， 根 据 View 的 
measure 过 程 ， 如 表 4-1 所 示 ， 构 造 此 种 MeasureSpec 需 要 知道 
parentSize， 即 父 容 右 的 剩余 空间 ， 而 这 个 时 候 我 们 无 法 知道 parentSize 
的 大 小 ， 所 以 理论 上 不 可 能 测量 出 View 的 大 小 。 


具体 的 数值 (dp/px) 
比如 宽 / 高 都 是 100px， 如 下 measure: 


int widthMeasureSpec = MeasureSpec.makeMeasureSpec(100,Measur 
EXACTLY); 
int heightMeasureSpec = MeasureSpec.makeMeasureSpec(100, Measu 
EXACTLY); 


view.measure(widthMeasureSpec, heightMeasureSpec ) ; 


wrap_content 


如 下 measure: 


int widthMeasureSpec = MeasureSpec.makeMeasureSpec( (1 << 30) 
MeasureSpec.AT_MOST); 
int heightMeasureSpec = MeasureSpec.makeMeasureSpec( (1 << 30 
MeasureSpec.AT_MOST); 


view.measure(widthMeasureSpec, heightMeasureSpec ) ; 


注意 到 (1 << 30)-1， 通 过 分 析 MeasureSpec 的 实现 可 以 知道 ，View 的 
尺寸 使 用 30 位 二 进 制 表示 ， 也 就 是 说 最 大 古 30 个 1( 即 2^30 - 1) ， 也 就 
是 (1 << 30) - 1， 在 最 大 化 模式 下 ， 我 们 用 View 理 论 上 能 文 持 的 最 大 值 
去 构造 MeasureSpec 是 合理 的 。 





关于 View 的 measure， 网 络 上 有 两 个 错误 的 用 法 。 为 什么 说 是 错误 
的 ， 首 先 其 违背 了 系统 的 内 部 实现 规范 (因为 无 法 通过 错误 的 
MeasureSpec 去 得 出 合法 的 SpecMode， 从 而 导致 measure 过 程 出 错 ) ， 其 
次 不 能 保证 一 定 能 measure 出 正确 的 结果 。 





第 一 种 错误 用 法 : 


int widthMeasureSpec = MeasureSpec.makeMeasureSpec(-1,Measure 
UNSPECIFIED); 
int heightMeasureSpec = MeasureSpec.makeMeasureSpec(-1,Measur 
UNSPECIFIED); 


view.measure(widthMeasureSpec, heightMeasureSpec ) ; 


第 二 种 错误 用 法 : 


view.measure(LayoutParams.WRAP_CONTENT, LayoutParams .WRAP_CONT 


4.3.2 layout 过程 


Layout 的 作用 是 ViewGroup 用 来 确定 子 元 素 的 位 置 ， 当 ViewGroup 
的 位 置 被 确定 后 ， 它 在 onLayout 中 会 所 历 所 有 的 子 元 素 并 调用 其 layonut 
方法 ， 在 layonut 方 法 中 onLayonut 方 法 又 会 被 调用 。Layout 过 程 和 measure 
过 程 相 比 就 简单 多 了 ，layout 方 法 确定 View 本 里 的 位 置 ， 而 onLayout 方 
法 则 会 确定 所 有 子 元 素 的 位 置 ， 先 看 View 的 layout 方 法 ， 如 下 所 示 。 








public void layout(int 1,int t,int r,int b) { 
if ((mPrivateFlags3 & PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT 
onMeasure(mOldwidthMeasureSpec, mOldHeightMeasureS 


mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_L 


int oldL = mLeft; 

int oldT = mTop; 

int oldB = mBottom; 

int oldR = mRight; 

boolean changed = isLayoutModeOptical(mParent) ? 

setOpticalFrame(1,t,r,b) : setFrame(1,t,r 

if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == 
onLayout(changed,1,t,r,b); 
mPrivateFlags &= ~PFLAG_LAYOUT_REQUIRED; 
ListenerInfo li = mListenerInfo; 
if (li != null && 11.mOnLayoutChangeListeners != 


ArrayList<OnLayoutChangeListener> listene 


(ArrayList<OnLayoutChange 
int numListeners = listenersCopy.size(); 
for (int i = 0; i < numListeners; ++i) { 


listenersCopy.get(i).onLayoutChan 


J 
mPrivateFlags &= ~PFLAG_FORCE_LAYOUT; 


mPrivateFlags3 |= PFLAG3_IS_LAID_OUT; 


layout 方 法 的 大 致 流程 如 下 : 首先 会 通过 setFrame 方 法 来 设 定 View 
的 四 个 顶点 的 位 置 ， 即 初始 化 mLeft、mRight、mTop 和 mBottom 这 四 个 
值 ，View 的 四 个 顶点 一 旦 确定 ， 那 么 View 在 父 容器 中 的 位 置 也 就 确定 
了 ; 接着 会 调用 onLayout 方 法 ， 这 个 方法 的 用 途 是 父 容 右 确定 子 元 素 的 
位 置 ， 和 onMeasure 方 法 类 似 ，onLayout 的 具体 实现 同样 和 具体 的 布局 
有 关 ， 所 以 View 和 ViewGroup 均 没有 真正 实现 onLayout 方 法 。 接 下 来 ， 
我 们 可 以 看 一 下 LinearLayout 的 onLayout 方 法 ， 如 下 所 示 。 











protected void onLayout(boolean changed,int 1,int t,int r,int 
if (mOrientation == VERTICAL) { 
layoutVertical(1,t,r,b); 
} else { 
layoutHorizontal(1,t,r,b); 


LinearLayout 中 onLayout 的 实现 逻辑 和 onMeasure 的 实现 逻辑 类 似 ， 


这 里 选择 layoutVertical 继 续 讲解 ， 为 了 更 好 地 理解 其 逻辑 ， 这 里 只 给 出 
了 主要 的 代码 : 





这 里 分 析 一 下 layoutVertical 的 代码 逻辑 ， 可 以 看 到 ， 此 方法 会 表 历 
所 有 子 元 素 并 调用 setChildFrame 方 法 来 为 子 元 素 指 定 对 应 的 位 置 ， 其 中 
childTop 会 逐渐 增 大 ， 这 就 意味 着 后 面 的 子 元 素 会 被 放置 在 靠 下 的 位 
置 ， 这 刚好 符合 竖 直 方向 的 LinearLayout 的 特性 。 至 于 setChildFrame， 
它 仅仅 是 调用 T en eal 己 ， 这 样 父 元 素 在 layout 方 法 中 完成 
目 己 的 定位 以 后 ， 就 通 ee de aoi 
元 素 叉 会 通过 自己 的 layout 方 法 来 确定 目 己 的 位 置 ， 这 样 一 层 一 层 地 传 
递 下 去 就 完成 了 整个 View 树 的 layout 过 程 。setChildFrame 方 法 的 实现 如 
下 所 示 。 























private void setChildFrame(View child,int left,int top,int wi 
height) { 

child.layout(left, top, left + width,top + height); 
J; 


我 们 注意 到 ，setChildFrame 中 ees a bn Ete FIG 
测量 宽 / 高 ， 从 下 面 的 代码 可 以 看 出 这 





final int childWidth = child.getMeasuredwidth(); 

final int childHeight = child.getMeasuredHeight(); 
setChildFrame(child, childLeft,childTop + getLocationOffset(ch 
childWidth, childHeight ) ; 


而 在 layout 方 法 中 会 通 人 设置 子 元 素 的 四 个 顶点 的 位 置 ， 
在 setFrame 中 有 如 下 几 人 句 赋值 语句 ， 这 样 一 来 子 元 素 的 位 置 束 确定 了 : 


mLeft = left; 


mTop = top; 


mRight = right; 


mBottom = bottom; 


PERRI 4484.38.25 Fe BAY Tale: | View 的 测量 宽 /高 和 
最 终 / 宽 高 有 什么 区 别 ? 这 个 问题 可 以 具体 为 : View 的 getMeasuredWidth 
和 getWidth 这 两 个 方法 有 什么 区 别 ， 至 于 getMeasuredHeight 和 getHeight 
的 区 别 和 前 两 者 完全 一 样 。 为 了 回答 这 个 问题 ， 首 先 ， 我 们 看 一 下 
getwidth 和 getHeight 这 两 个 方法 的 具体 实现 : 


public final int getwidth() { 
return mRight -mLeft; 

} 

public final int getHeight() { 
return mBottom -mTop; 


} 


从 getWidth 和 getHeight 的 源码 再 结合 mLeft、mRight、mTop 和 
mBottom 这 四 个 变量 的 赋值 过 程 来 看 ，getWidth 方 法 的 返回 值 刚 好 吏 是 
View 的 测量 宽度 ， 而 getHeight 方 法 的 返回 值 也 刚好 就 是 View 的 测量 高 
度 。 经 过 上 述 分 析 ， 现 在 我 们 可 以 回答 这 个 问题 了 : 在 View 的 默认 实现 
中 ，View 的 测量 宽 / 高 和 最 终 宽 / 高 是 相等 的 ， 只 不 过 测量 宽 / 高 形成 于 
View 的 measure 过 程 ， 而 最 终 宽 /高 形成 于 View 的 layout 过 程 ， 即 两 者 的 
赋值 时 机 不 同 ， 测 量 宽 / 高 的 赋值 时 机 稍微 时 一些 。 因 此 ， 在 日 营 开 发 
中 ， 我 们 可 以 认为 View 的 测量 宽 / 高 就 等 于 最 终 宽 / 高 ， 但 是 的 确 存在 某 
些 特殊 情况 会 导致 两 者 不 一 致 ， 下 面 举例 说 明 。 


























如 果 重 写 View 的 layout 方 法 ， 代 码 如 下 : 


public void layout(int 1,int t,int r,int b) { 
super.layout(1,t,r + 100,b + 100); 











上 述 代码 会 导致 在 任何 情况 下 View 的 最 终 宽 /高 总 是 比 测量 宽 / 高 大 
100px， 虽 然 这 样 做 会 导 臻 View 显示 不 正常 并 且 也 没有 实际 意义 ， 但 是 
这 证 明了 测量 宽 / 高 的 确 可 以 不 等 于 最 终 宽 /高 。 另 外 一 种 情况 是 在 某 些 
情况 下 ，View 需 要 多 次 measure 才 能 确定 目 己 的 测量 宽 / 高 ， 在 前 几 次 的 
测量 过 程 中 ， 其 得 出 的 测量 宽 / 高 有 可 能 和 最 终 宽 /高 不 一 致 ， 但 最 终 来 
说 ， 测 量 宽 /高 还 是 和 最 终 宽 /高 相同 。 
































4.3.3 ”draw 过 程 

Draw 过 程 就 比较 简单 了 ， 它 的 作用 是 将 View 绘 制 到 屏幕 上 面 。 
View 的 绘制 过 程 遵循 如 下 几 步 : 

(1) 绘制 背景 background.draw(canvas)。 

(2) 绘制 上 自己 ConDraw) 。 

(3) 绘制 children (dispatchDraw) 。 

(4) 绘制 装饰 (onDrawScrollBars) 。 

这 一 点 通过 draw 方 法 的 源码 可 以 明显 看 出 来 ， 如 下 所 示 。 


public void draw(Canvas canvas) { 


final int privateFlags = mPrivateFlags; 


final boolean dirtyOpaque = (privateFlags & PFLAG_DIRTY_M 
(mAttachInfo == null || !mAttachInfo.mIgnoreDirty 
mPrivateFlags = (privateFlags & ~PFLAG_DIRTY_MASK) | PFLA 
/* 
* Draw traversal performs several drawing steps which mu 


* in the appropriate order: 


* 


* 


Draw the background 

If necessary,save the canvas' layers to prepar 
Draw view's content 

Draw children 


If necessary,draw the fading edges and restore 


* 
oO oO BR WwW N FB 


Draw decorations (scrollbars for instance) 
S 
// Step 1,draw the background, if needed 
int saveCount; 
if (!dirtyOpaque) { 
drawBackground(canvas ) ; 
Í 
// skip step 2 & 5 if possible (common case) 
final int viewFlags = mViewFlags; 
boolean horizontalEdges = (viewFlags & FADING_EDGE_HORIZO 
boolean verticalEdges = (viewFlags & FADING_EDGE_VERTICAL 
if (!verticalEdges && !horizontalEdges) { 
// Step 3,draw the content 
if (!dirtyOpaque) onDraw(canvas); 


// Step 4,draw the children 


View 绘 制 过 程 的 传递 是 通过 dispatchDraw 来 实现 的 ，dispatchDraw 
会 遍历 调用 所 有 子 元 素 的 draw 方 法 ， 如 此 draw 事 件 就 一 层 层 地 传递 了 下 


去 。View 有 一 个 特殊 的 方法 setWillNotDraw， 先 看 一 下 它 的 源码 ， 如 下 
所 示 。 





public void setWillNotDraw(boolean willNotDraw) { 
setFlags(willNotDraw ? WILL_NOT_DRAW : 0,DRAW_MASK); 


} 


从 setWillNotDraw 这 个 方法 的 注释 中 可 以 看 出 ， 如 果 一 个 View 不 需 
要 绘制 任何 内 容 ， 那 么 设置 这 个 标记 位 为 true 以 后 ， 系 统 会 进行 相应 的 
优化 。 默 认 情 况 下 ，View 没 有 局 用 这 个 优化 标记 位 ， 但 是 ViewGroup 会 
默认 局 用 这 个 优化 标记 位 。 这 个 标记 位 对 实际 开发 的 意义 是 : 当 我 们 的 
和 目 定 义 控 件 继承 于 ViewGroup 并 且 本 喘 不 具备 绘制 功能 时 ， 就 可 以 开启 
这 个 标记 位 从 而 便于 系统 进行 后 续 的 优化 。 当 然 ， 当 明确 知道 一 个 
ViewGroup 需 要 通过 onDraw 来 绘制 内 容 时 ， 我 们 需要 显 式 地 关闭 
WILL_NOT_DRAW 这 个 标记 位 。 











44 日 定义 View 


本 节 将 详细 介绍 自 定义 View 相 关 的 知识 。 自 定义 View 的 作用 不 用 
多 说 ， 这 个 读者 都 应 该 清楚 ， 如 果 想 要 做 出 绚丽 的 界面 效果 仅仅 靠 系统 
的 控件 是 远 远 不 够 的 ， 这 个 时 候 就 必须 通过 自 定义 View 来 实现 这 些 绚丽 
的 效果 。 自 定义 View 是 一 个 综合 的 技术 体系 ， 它 涉及 View 的 层次 结 
构 、 事 件 分 发 机 制 和 View 的 工作 原理 等 技术 细节 ， 而 这 些 技术 细节 每 一 
项 又 都 是 初学 者 难以 掌握 的 ， 因 此 就 不 难 理解 为 什么 初学 者 都 觉得 自 定 
义 View 很 难 这 一 现状 了 。 考 虑 到 这 一 点 ， 本 书 在 第 3 章 和 第 4 章 的 前 半 部 
分 对 自 定 义 View 的 各 种 技术 细节 都 做 了 详细 的 分 析 ， 目 的 就 是 为 了 让 读 
者 更 好 地 掌握 本 节 的 内 容 。 尽 管 自 定义 View 很 难 ， 其 至 面 对 各 种 复杂 的 
效果 时 往往 还 会 觉得 有 点 无 章 可 循 。 但 是 ， 本 节 将 从 一 定 高 度 来 重新 审 
视 自 定 义 View， 并 以 综述 的 形式 介绍 自 定 义 View 的 分 类 和 须知 ， 虽 在 
帮助 初学 者 能 够 透 过 现象 看 本 质 ， 避 免 陷 入 只 见 树 木 不 见 森林 的 状态 之 
中 。 同 时 为 了 让 读者 更 好 地 理解 自 定义 View， 在 本 节 最 后 还 会 针对 自 定 
义 View 的 不 同类 别 分 别提 供 一 个 实际 的 例子 ， 通 过 这 些 例子 能 够 让 读者 
更 深入 地 掌握 自 定义 View。 


























4.4.1 ” 自 定 义 View 的 分 类 


自 定 义 View 的 分 类 标准 不 唯一 ， 而 笔者 则 把 自 定 义 View 分 为 4 类 。 
1. 继承 View 重 写 onDraw 方 法 


这 种 方法 主要 用 于 实现 一 些 不 规则 的 效果 ， 即 这 种 效果 不 方便 通过 





布局 的 组 合 方式 来 达到 ， 往 往 需 要 静态 或 者 动态 地 显示 一 些 不 规则 的 图 
形 。 很 显然 这 需要 通过 绘制 的 方式 来 实现 ， 即 重 写 onDraw 方 法 。 采 用 
这 种 方式 需要 自己 文 持 wrap_content， 并 且 padding 也 需要 自己 处 理 。 





2. 继承 ViewGroup 派 生 特殊 的 Layout 


这 种 方法 主要 用 于 实现 自 定义 的 布局 ， 即 除 了 LinearLayout、 
RelativeLayout、FrameLayout 这 几 种 系统 的 布局 之 外 ， 我 们 重新 定义 一 
种 新 布局 ， 当 某 种 效果 看 起 来 很 像 几 种 View 组 合 在 一 起 的 时 候 ， 可 以 采 
用 这 种 方法 来 实现 。 采 用 这 种 方式 稍微 复杂 一 些 ， 需 要 合适 地 处 理 
ViewGroup 的 测量 、 布 局 这 两 个 过 程 ， 并 同时 处 理子 元 素 的 测量 和 布局 








3. 继承 特定 的 View (比如 TextView) 


这 种 方法 比较 常见 ， 一 般 是 用 于 扩展 某 种 已 有 的 View 的 功能 ， 比 如 
TextView， 这 种 方法 比较 容易 实现 。 这 种 方法 不 需要 上 自己 支持 


wrap_content 和 padding 等 。 
4. 继承 特定 的 ViewGroup 比如 LinearLayout) 


这 种 方法 也 比较 币 见 ， 当 茶 种 效果 看 起 来 很 像 几 种 View 组 合 在 一 起 
的 时 候 ， 可 以 采用 这 种 方法 来 实现 。 采 用 这 种 方法 不 需要 目 己 处 理 
ViewGroup 的 测量 和 布局 这 两 个 过 程 。 需 要 注意 这 种 方法 和 方法 2 的 区 
别 ， 一 般 来 说 方法 2 能 实现 的 效果 方法 4 也 都 能 实现 ， 两 者 的 主要 差别 在 
于 方法 2 更 接近 View 的 底层 。 











上 面 介绍 了 自 定义 View 的 4 种 方式 ， 读 者 可 以 仔细 体会 一 下 ， 古 不 
是 的 确 可 以 这 么 划分 ? 但 是 这 里 要 说 的 是 ， 目 定义 View 讲 客 的 是 灵活 


性 ， 一 种 效果 可 能 多 种 方法 都 可 以 实现 ， 我 们 需要 做 的 就 是 找到 一 种 代 
价 最 小 、 最 高 效 的 方法 去 实现 ， 在 4.4.2 节 会 列举 一 些 自 定 义 View 过 程 中 
常见 的 注意 事项 。 





4.4.2” 自 定义 View 须 知 


本 市 将 介绍 自 定 义 View 过 程 中 的 一 些 注意 事项 ， 这 些 问题 如 果 人 处 理 
不 好 ， 有 些 会 影响 View 的 正常 使 用 ， 而 有 些 则 会 导致 内 存 泄露 等 ， 具 体 
的 注意 事项 如 下 所 示 。 


1. 让 View 支 持 wrap_content 


这 是 因为 直接 继承 View 或 者 ViewGroup 的 控件 ， 如 果 不 在 
onMeasure 中 对 wrap_content 做 特殊 处 理 ， 那 么 当 外 界 在 布局 中 使 用 
wrap_content 时 就 无 法 达到 预期 的 效果 ， 有 具体 情形 已 经 在 4.3.1 节 中 进行 
了 详细 的 介绍 ， 这 里 不 再 重复 了 。 





2. 如 果 有 必要 ， 让 你 的 View 支 持 padding 





这 是 因为 直接 继承 View 的 控件 ， 如 果 不 在 draw 方 法 中 处 理 
padding， 那 么 padding 属 性 是 无 法 起 作用 的 。 另 外 ， 直 接 继承 自 
ViewGroup 的 控件 需要 在 onMeasure 和 onLayout 中 考虑 padding 和 子 元 素 
的 margin 对 其 造成 的 影响 ， 不 然 将 导致 padding 和 子 元 素 的 margin 失 效 。 


3. 尽量 不 要 在 View 中 使 用 Handler， 没 必要 


这 是 因为 View 内 部 本 号 就 提供 了 post 系 列 的 方法 ， 完 全 可 以 葵 代 
Handler 的 作用 ， 当 然 除 非 你 很 明确 地 要 使 用 Handler 来 发 送 消息 。 
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View#onDetachedFromWindow 





这 一 条 也 很 好 理解 ， 如 果 有 线程 或 者 动画 需要 停止 时 ， 那 么 
onDetachedFromWindow 是 一 个 很 好 的 时 机 。 当 包含 此 View 的 Activity 退 
出 或 者 当前 View 被 remove 时 ，View 的 onDetachedFromWindow 方 法 会 被 
调用 ， 和 此 方法 对 应 的 是 onAttachedToWindow， 当 包含 此 View 的 
Activity 启 动 时 ，View 的 onAttachedToWindow 方 法 会 被 调用 。 同 时 ， 当 
View 变 得 不 可 见 时 我 们 也 需要 停止 线程 和 动画 ， 如 果 不 及 时 处 理 这 种 问 
rl, AA RESTA Fi o 








5. View 市 有 滑动 散人 套 情 形 时 ， 需 要 人 处理 好 滑动 冲突 





如 果 有 滑动 冲突 的 话 ， 那 么 要 合适 地 处 理 滑 动 冲突 ， 人 否则 将 会 严重 
影响 View 的 效果 ， 具 体 怎 么 解决 滑动 冲突 请 参看 第 3 章 。 














44.3 Hie XViewx Bl 


4.4.1 攻 和 4.4.2 节 分 别 介 绍 了 目 定义 View 的 类 别 和 注意 事项 ， 本 将 
通过 几 个 实际 的 例子 来 演示 如 何 自 定义 一 个 规范 的 View， 通 过 本 市 的 例 
子 再 结合 上 面 两 节 的 内 容 ， 可 以 让 读者 更 好 地 掌握 目 定义 View。 下 面 仍 
然 按 照 目 定义 View 的 分 类 来 介绍 具体 的 实现 细节 。 


1. 继承 View 重 写 onDraw 方 法 


这 种 方法 主要 用 于 实现 一 些 不 规则 的 效果 ， 一 般 需 要 重 写 onDraw 
方法 。 采 用 这 种 方式 需要 自己 文 持 wrap_content， 并 且 padding 也 需要 上 自 
己 处 理 。 下 面 通过 一 个 具体 的 例子 来 演示 如 何 实现 这 种 自 定 义 View。 








为 了 更 好 地 展示 一 些 平 时 不 容易 注意 到 的 问题 ， 这 里 选择 实现 一 个 
很 简单 的 自 定 义 控件 ， 简 单 到 只 是 绘制 一 个 圆 ， 尽 管 如 此 ， 需 要 注意 的 
细节 还 是 很 多 的 。 为 了 实现 一 个 规范 的 控件 ， 在 实现 过 程 中 必须 考虑 到 
wrap_content 模 式 以 及 padding， 同 时 为 了 提高 便捷 性 ， 还 要 对 外 提供 自 
定义 属性 。 我 们 先 来 看 一 下 最 简单 的 实现 ， 代 码 如 下 所 示 。 





int width = getWidth(); 
int height = getHeight(); 
int radius = Math.min(width,height) / 2; 


canvas.drawCircle(width / 2,height / 2,radius,mPaint 


上 面 的 代码 实现 了 一 个 具有 圆 形 效 果 的 自 定义 View， 它 会 在 上 自己 的 
中 心 点 以 宽 / 高 的 最 小 值 为 直径 绘制 一 个 红色 的 实心 圆 ， 它 的 实现 很 简 
单 ， 并 且 上 面 的 代码 相信 大 部 分 初学 者 都 能 写 出 来 ， 但 是 不 得 不 说 ， 上 
面 的 代码 只 是 一 种 初级 的 实现 ， 并 不 是 一 个 规范 的 目 定 义 View， 为 什么 
A Pie? 我 们 通过 调整 布局 参数 来 对 比 一 下 。 














请 看 下 面 的 布局 : 


<LinearLayout xmlns:android="http://schemas.android.com/apk/r 
xmins:tools="http://schemas.android.com/tools" 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android: background="#ffffTfF" 
android:orientation="vertical" > 
<com.ryg.chapter_4.ui.CircleView 
android: id="@+tid/circleView1i" 
android: Layout_width="match_parent" 
android: Llayout_height="100dp" 
android: background="#000000"/> 


</LinearLayout> 


再 看 一 下 运行 的 效果 ， 如 图 4-3 中 的 〈1) 所 示 ， 这 是 我 们 预期 的 效 
果 。 接 着 再 调整 CircleView 的 布局 参数 ， 为 其 设置 20dp 的 margin， 调 整 
后 的 布局 如 下 所 示 。 


<com.ryg.chapter_4.ui.CircleView 
android: id="@+id/circleView1i" 
android: Layout_width=" match_parent" 
android: Llayout_height="100dp" 
android: Layout_margin="20dp" 


android: background="#000000"/> 


运行 后 看 一 下 效果 ， 如 图 4-3 中 的 〈2) 所 示 ， 这 也 是 我 们 预期 的 效 
果 ， 这 说 明 margin 属 性 是 生效 的 。 这 是 因为 margin 属 性 是 由 父 容器 控制 
的 ， 因 此 不 需要 在 CircleView 中 做 特殊 处 理 。 再 调整 CircleView 的 布局 
参数 ， 为 其 设置 20dp 的 padding， 如 下 所 示 。 


<com.ryg.chapter_4.ui.CircleView 
android: id="@+id/circleView1i" 
android: Llayout_width="match_parent" 
android: Llayout_height="100dp" 
android: Llayout_margin="20dp" 
android: padding="20dp" 
android: background="#000000"/> 


运行 后 看 一 下 效果 ， 如 图 4-3 中 的 〈3) 所 示 。 结 果 发 现 padding 根 本 
没有 生效 ， 这 就 是 我 们 在 前 面 提 到 的 直接 继承 自 View 和 ViewGroup 的 控 
件 ，padding 是 默认 无 法 生效 的 ， 需 要 自己 处 理 。 再 调整 一 下 CircleView 
的 布局 参数 ， 将 其 宽度 设置 为 wrap_content， 如 下 所 示 。 


<com.ryg.chapter_4.u1.CircleView 
android: id="@+id/circleView1i" 
android: Llayout_width="Wrap_content" 
android: Llayout_height="100dp" 
android: Llayout_margin="20dp" 
android: padding="20dp" 
android: background="#000000"/> 


运行 后 看 一 下 效果 ， 如 图 4-3 中 的 〈4) 所 示 ， 结 果 发 现 
wrap_content 并 没有 达到 预期 的 效果 。 对 比 下 “3〉 和 (4) 的 效果 图 ， 
发 现 宽度 使 用 wrap_content 和 使 用 match_parent 没 有 任何 区 别 。 的 确 是 这 
样 的 ， 这 一 点 在 前 面 也 已 经 提 到 过 : 对 于 直接 继承 自 View 的 控件 ， 如 果 
不 对 wrap_content 做 特殊 处 理 ， 那 么 使 用 wrap_content 就 相当 于 使 用 


match_parent。 





Chapter4Ciclevew 
a) (2) 
Chapter -4:CircleView — Chapter&GircleView 
(3) (4) 
图 4-3 CircleView 运 行 效果 图 


为 了 解决 上 面 提 到 的 几 种 问题 ， 我 们 需要 做 如 下 处 理 : 


首先 ， 针 对 wrap_content 的 问题 ， 其 解决 方法 在 4.3.1 节 中 已 经 做 了 
详细 的 介绍 ， 这 里 只 需要 指定 一 个 wrap_content 模 式 的 默认 宽 / 高 即 可 ， 
比如 选择 200px 作 为 默认 的 宽 / 高 。 


其 次 ， 针 对 padding 的 问题 ， 也 很 简单 ， 只 要 在 绘制 的 时 候 考 虑 一 
下 padding 即 可 ， 因 此 我 们 需要 对 onDraw 稍 微 做 一 下 修改 ， 修 改 后 的 代 
码 如 下 所 示 。 


protected void onDraw(Canvas canvas) { 
super .onDraw(canvas); 
final int paddingLeft = getPaddingLeft(); 
final int paddingRight = getPaddingLeft(); 
final int paddingTop = getPaddingLeft(); 
final int paddingBottom = getPaddingLeft(); 
int width = getWidth() -paddingLeft -paddingRight; 
int height = getHeight() -paddingTop -paddingBottom; 
int radius = Math.min(width,height) / 2; 
canvas.drawCircle(paddingLeft + width / 2,paddingTop + he 


mPaint); 


上 面 的 代码 很 简单 ， 中 心思 想 就 是 在 绘制 的 时 候 考 虑 到 View 四 周 的 
空白 即 可 ， 其 中 圆心 和 半径 都 会 考虑 到 View 四 周 的 padding， 从 而 做 相 
应 的 调整 。 


<com.ryg.chapter_4.ui.CircleView 
android: id="@+id/circleView1i" 


android: Layout_width="wrap_content" 


android: layout_height="100dp" 
android: Llayout_margin="20dp" 
android: padding="20dp" 
android: background="#000000"/> 





针对 上 面 的 布局 参数 ， 我 们 再 次 运行 一 下 ， 结 果 如 图 4-4 中 的 《1) 
所 示 ， 可 以 发 现 布局 参数 中 的 wrap_content 和 padding 均 生效 了 。 





图 4-4 CircleView 运 行 效果 图 


最 后 ， 为 了 让 我 们 的 View 更 加 容易 使 用 ， 很 多 情况 下 我 们 还 需要 为 
其 提供 目 定义 属性 ， 像 android:layout_width 和 android:padding 这 种 以 
android 开 头 的 属性 是 系统 自 带 的 属性 ， 那 么 如 何 添加 自 定义 属性 呢 ? 这 
也 不 是 什么 难事 ， 遵 循 如 下 几 步 : 


第 一 步 ， 在 values 目 录 下 面 创建 自 定义 属性 的 XML， 比 如 
attrs.xXml， 也 可 以 选择 类 似 于 attrs_circle_view.xml 等 这 种 以 attrs_ 开头 的 
文件 名 ， 当 然 这 个 文件 名 并 没有 什么 限制 ， 可 以 随便 取 名 字 。 针 对 本 例 
来 说 ， 选 择 创 建 attrs.xml 文 件 ， 文 件 内 容 如 下 : 


<?xml version="1.0" encoding="utf-8"?> 
<resources> 
<declare-styleable name="CircleView"> 


<attr name="circle color" format="color" /> 


</declare-styleable> 


</resources> 


在 上 面 的 XML 中 声明 了 一 个 自 定义 属性 集合 “CircleView”， 在 这 个 
集合 里 面 可 以 有 很 多 自 定义 属性 ， 这 里 只 定义 了 一 个 格式 为 “color” 的 属 
性 “circle_color”， 这 里 的 格式 color 指 的 是 颜色 。 除 了 颜色 格式 ， 自 定义 
属性 还 有 其 他 格式 ， 比 如 reference 是 指 资源 id，dimension 是 指 尺 寸 ， 而 
像 string、 as 文 种 是 指 基 本 数据 类 型 。 除 了 列举 的 这 些 还 
有 其 他 类 型 ， 这 里 藉 不 一 一 描述 了 ， 读 者 得 看 一 下 文档 即 可 ， 这 并 没有 
什么 难度 。 











第 二 步 ， 在 View 的 构造 方法 中 解析 目 定 义 属性 的 值 并 做 相应 处 理 。 
对 于 本 例 来 说 ， 我 们 需要 解析 circle_color 这 个 属性 的 值 ， 代 码 如 下 所 
不 。 


public CircleView(Context context,AttributeSet attrs,int defS 
super (context,attrs,defStyleAttr); 
TypedArray a = context.obtainStyledAttributes(attrs,R.sty 
mColor = a.getColor(styleable.CircleView_circle_color,Col 
a.recycle(); 


init(); 


这 看 起 来 很 简单 ， 首 先 加 载 自 定义 属性 集合 CircleView， 接 着 解析 
CircleView 属 性 集合 中 的 circle_color 属 性 ， 它 ie id 为 
R.styleable.CircleView_circle_color。 在 这 一 步骤 中 ， 如 果 在 使 用 时 没有 

ee T ee ee 解析 
完 目 定义 属性 后 ， 通 过 recycle 方 法 来 实现 资源 ， 这 样 CircleView 中 所 做 
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第 三 步 ， 在 布局 文件 中 使 用 目 定 义 属 性 ， 如 下 所 示 。 


<LinearLayout xmlns:android="http://schemas.android.com/apk/r 

xmins:app="http://schemas.android.com/apk/res-auto" 
android: Layout_width="match_parent" 
android: Llayout_height="match_parent" 
android: background="#fffffF" 
android:orientation="vertical" > 
<com.ryg.chapter_4.ui.CircleView 

android: id="@+id/circleView1i" 

android: Layout_width="wrap_content" 

android: Llayout_height="100dp" 

android: Llayout_margin="20dp" 

app:circle_color="@color/light_green" 

android: padding="20dp" 

android: background="#000000"/> 


</LinearLayout> 


上 面 的 布局 文件 中 有 一 点 需要 注意 ， 首 先 ， 为 了 使 用 自 定 义 属 性 ， 
必须 在 布局 文件 中 添加 schemas 声 明 : 

xmlns:app=http://schemas.android.com/apk/res-auto。 在 这 个 声明 中 ，app 
是 目 定 义 属性 的 前 经， 当然 可 以 换 其 他 名 字 ， 但 是 CircleView 中 的 自 害 
义 属 性 的 前 缀 必须 和 这 里 的 一 致 ， 然 后 就 可 以 在 CircleView 中 使 用 目 定 
义 属性 了 ， 比 如 : app:circle_color="@color/light_green". 4, HATE 
照 如 下 方式 声明 schemas: 

xmlns:app=http://schemas.android.com/apk/res/com.ryg.chapter 4， 这 种 方 








式 会 在 apk/res/ 后 面 附加 应 用 的 包 名 。 但 是 这 两 种 方式 并 没有 本 质 区 别 ， 
笔者 比较 喜欢 的 是 xmlns:app=http://schemas.android.com/apk/res-auto 这 种 
声明 方式 。 








到 这 里 自 定义 属性 的 使 用 过 程 束 完成 了 ， 运 行 一 下 程序 ， 效 果 如 图 
4-4 中 的 (2) 所 示 ， 很 显然 ，CircleView 的 自 定义 属性 circle_color 生 效 
了 。 下 面 给 出 CircleView 的 完整 代码 ， 这 时 的 CircleView 已 经 是 一 个 很 
规范 的 自 定义 View 了 ， 如 下 所 示 。 


public class CircleView extends View { 

private int mColor = Color.RED; 

private Paint mPaint = new Paint(Paint.ANTI_ALIAS_ FLAG); 

public CircleView(Context context) { 
super (context); 
init(); 

} 

public CircleView(Context context,AttributeSet attrs) { 
this(context,attrs,0); 

} 

public CircleView(Context context,AttributeSet attrs,int 
super (context,attrs,defStyleAttr); 
TypedArray a = context.obtainStyledAttributes(attrs, 
mColor = a.getColor(R.styleable.CircleView_circle_co 
a.recycle(); 
init(); 

} 


private void init() { 


mPaint.setColor(mColor); 
} 
@Override 
protected void onMeasure(int widthMeasureSpec, int height 
super .onMeasure(widthMeasureSpec, heightMeasureSpec) ; 
int widthSpecMode = MeasureSpec.getMode(widthMeasure 
int widthSpecSize = MeasureSpec.getSize(widthMeasure 
int heightSpecMode = MeasureSpec.getMode(heightMeasu 
int heightSpecSize = MeasureSpec.getSize(heightMeasu 
if (widthSpecMode == MeasureSpec.AT_MOST && heightSp 
MeasureSpec.AT_MOST) { 
setMeasuredDimension(200, 200); 
} else if (widthSpecMode == MeasureSpec.AT_MOST) { 
setMeasuredDimension( 200, heightSpecSize) ; 
} else if (heightSpecMode == MeasureSpec.AT_MOST) { 


setMeasuredDimension(widthSpecSize, 200); 


} 


@Override 
protected void onDraw(Canvas canvas) { 
super .onDraw(canvas); 
final int paddingLeft = getPaddingLeft(); 
final int paddingRight = getPaddingLeft(); 
final int paddingTop = getPaddingLeft(); 
final int paddingBottom = getPaddingLeft(); 
int width = getWidth() -paddingLeft -paddingRight; 


int height = getHeight() -paddingTop -paddingBottom; 


int radius = Math.min(width,height) / 2; 
canvas.drawCircle(paddingLeft + width / 2,paddingTop 


radius, mPaint); 


} 
2. 继承 ViewGroup 派 生 特殊 的 Layonut 


这 种 方法 主要 用 于 实现 自 定 义 的 布局 ， 采 用 这 种 方式 稍微 复杂 一 
些 ， 需 要 合适 地 处 理 ViewGroup 的 测量 、 布 局 这 两 个 过 程 ， 并 同时 处 理 
子 元 素 的 测量 和 布局 过 程 。 在 第 3 章 的 3.5.3 节 中 ， 我 们 分 析 了 滑动 冲突 
的 两 种 方式 并 实现 了 两 个 自 定 义 View: HorizontalScroll-ViewEx 和 
StickyLayout， 其 中 HorizontalScrollViewEx 就 是 通过 继承 ViewGroup 来 实 
现 的 自 定义 View， 这 里 会 再 次 分 析 它 的 measure 和 ]layout 过 程 。 





需要 说 明 的 是 ， 如 条 要 采用 此 种 方法 实现 一 个 很 规范 的 自 定 义 
View， 是 有 一 定 的 代价 的 ， 这 点 通过 查看 LinearLayout 等 的 源码 就 知 
道 ， 它 们 的 实现 都 很 复杂 。 对 于 Horizontal-ScrollViewEx 来 说 ， 这 里 不 
打算 实现 它 的 方方面面 ， 仅 仅 是 完成 主要 功能 ， 但 是 需要 规范 化 的 地 方 
会 给 出 说 明 。 





这 里 再 回顾 一 下 HorizontalScrollViewEx 的 功能 ， 它 主要 是 一 个 类 似 
于 ViewPager 的 控件 ， 也 可 以 说 是 一 个 类 似 于 水 平方 向 的 LinearLayout 的 
控件 ， 它 内 部 的 子 元 素 可 以 进行 水 平滑 动 并 且 子 元 素 的 内 部 还 可 以 进行 
竖 直 滑动 ， 这 显然 是 存在 滑动 冲突 的 ， 但 是 HorizontalScrollViewEx 内 部 
解决 了 水 平和 竖 直 方 同 的 滑动 冲突 问题 。 关 于 HorizontalScrollViewEx 古 
如 何 解 决 滑动 冲突 的 ， 请 参看 第 3 章 的 相关 内 容 。 这 里 有 一 个 假设 ， 那 
就 是 所 有 子 元 素 的 宽 / 高 都 是 一 样 的 。 下 面 主要 看 一 下 它 的 onMeasure 和 





























onLayout 方 法 的 实现 ， 先 看 onMeasure， 如 下 所 示 。 


protected void onMeasure(int widthMeasureSpec, int heightMeasu 
super .onMeasure(widthMeasureSpec, heightMeasureSpec ) ; 
int measuredwidth = 0; 
int measuredHeight = 0; 
final int childCount = getChildCount(); 
measureChildren(widthMeasureSpec, heightMeasureSpec) ; 
int widthSpaceSize = MeasureSpec.getSize(widthMeasureSpec 
int widthSpecMode = MeasureSpec.getMode(widthMeasureSpec ) 
int heightSpaceSize = MeasureSpec.getSize(heightMeasureSp 
int heightSpecMode = MeasureSpec.getMode(heightMeasureSpe 
if (childCount == 0) { 
setMeasuredDimension(0,0); 
} else if (widthSpecMode == MeasureSpec.AT_MOST && height 
MeasureSpec.AT_MOST) { 
final View childView = getChildAt(0); 
measuredwidth = childView.getMeasuredwidth() * ch 
measuredHeight = childView.getMeasuredHeight(); 
setMeasuredDimension(measuredwidth, measuredHeight 
} else if (heightSpecMode == MeasureSpec.AT_MOST) { 
final View childView = getChildAt(0); 
measuredHeight = childView.getMeasuredHeight()j; 
setMeasuredDimension(widthSpaceSize, childView.get 
Height()); 
} else if (widthSpecMode == MeasureSpec.AT_MOST) { 
final View childView = getChildAt(0); 


measuredwidth = childView.getMeasuredwidth() * ch 


setMeasuredDimension(measuredwidth, heightSpaceSiz 








这 里 说 明 一 下 上 述 代码 的 逻辑 ， 首 先 会 判断 是 否 有 子 元 素 ， 如 果 没 
有 子 元 素 就 直接 把 自己 的 宽 / 高 设 为 0; 然后 束 是 判断 宽 和 高 是 不 是 采用 
了 wrap_content， 如 果 宽 采用 了 wrap_content， 那 么 
HorizontalScrollViewEx 的 宽度 惑 是 所 有 子 元 素 的 宽度 之 和 ; WR ay BE 
用 了 wrap_content， 那 么 HorizontalScrollViewEx 的 高 度 就 是 第 一 个 子 元 
素 的 高 度 。 





























上 述 代码 不 太 规范 的 地 方 有 两 点 : 第 一 点 是 没有 子 元 素 的 时 候 不 应 
该 直接 把 宽 / 高 设 为 0， 而 应 该 根据 LayoutParams 中 的 宽 / 高 来 做 相应 处 
H, 第 二 点 是 在 测量 HorizontalScrollViewEx 的 宽 / 高 时 没有 考虑 到 它 的 
padding 以 及 子 元 素 的 margin， 因 为 它 的 padding 以 及 子 元 素 的 margin 会 影 
啊 到 HorizontalScrollViewEx 的 宽 / 高 。 这 是 很 好 理解 的 ， 因 为 不 管 是 自 
己 的 padding 还 是 子 元 素 的 margin， 占 用 的 都 是 HorizontalScrollViewEx 的 


空间 。 








接着 再 看 一 下 HorizontalScrollViewEx 的 onLayout 方 法 ， 如 下 所 示 。 


protected void onLayout(boolean changed,int 1,int t,int r,int 
int childLeft = 0; 
final int childCount = getChildCount(); 
mChildrenSize = childCount; 
for (int i = 0; i < childCount; i++) { 


final View childView = getChildAt(i); 


if (childView.getVisibility() != View.GONE) { 
final int childwidth = childView.getMeasu 
mChildwidth = childwidth; 
childView. layout(childLeft,0,childLeft + 
childView. getMeasuredHeig 


childLeft += childwidth; 
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过 layout 方 法 将 其 放置 在 合适 的 位 置 上 。 从 代码 上 来 看 ， 这 个 放置 过 程 
是 由 左 向 右 的 ， 这 和 水 平方 向 的 LinearLayout 比 较 类 似 。 上 述 代码 的 不 
完美 之 处 仍然 在 于 放置 子 元 素 的 过 程 没 有 考虑 到 Ha padding Ae 
元 系 的 margin， 而 从 一 个 规范 的 控件 的 角度 来 看 ， 这 些 都 是 应 该 考虑 
的 。 下 面 给 出 Horizontal-ScrollViewEx 的 完整 代码 ， 如 下 所 示 。 





public class HorizontalScrollViewEx extends ViewGroup { 
private static final String TAG = "HorizontalScrollViewE 
private int mChildrenSize; 
private int mChildwidth; 
private int mChildIndex; 
// 分 别 记录 上 次 滑动 的 坐标 
private int mLastX = 0; 
private int mLastY = 0; 


// 分 别 记录 上 次 滑动 的 坐标 (onInterceptTouchEvent) 














i 


int widthSpaceSize = MeasureSpec.getSize(widthMeasur 

int widthSpecMode = MeasureSpec.getMode(widthMeasure 

int heightSpaceSize = MeasureSpec.getSize(heightMeas 

int heightSpecMode = MeasureSpec.getMode(heightMeasu 

if (childCount == 0) { 
setMeasuredDimension(0,0); 

} else if (widthSpecMode == MeasureSpec.AT_MOST && h 

MeasureSpec.AT_MOST) { 
final View childView = getChildAt(0); 
measuredwidth = childView.getMeasuredwWidth() * c 
measuredHeight = childView.getMeasuredHeight(); 
setMeasuredDimension(measuredwidth, measuredHeigh 

} else if (heightSpecMode == MeasureSpec.AT_MOST) { 
final View childView = getChildAt(0); 
measuredHeight = childView.getMeasuredHeight(); 
setMeasuredDimension(widthSpaceSize, childView.ge 
Height()); 

} else if (widthSpecMode == MeasureSpec.AT_MOST) { 
final View childView = getChildAt(0); 
measuredwidth = childView.getMeasuredwidth() * c 


setMeasuredDimension(measuredwidth, heightSpaceSi 


@Override 


protected void onLayout(boolean changed,int 1,int t,int 


int childLeft = 0; 
final int childCount = getChildCount(); 





} 


继承 特定 的 View( 比 如 TextView) 和 继承 特定 的 ViewGroup 〈 比 如 
LinearLayout) 这 两 种 方式 比较 简单 ， 这 里 就 不 再 举例 说 明了 ， 关 于 第 3 
章 中 提 到 的 StickyLayout 的 具体 实现 ， 大 家 可 以 参看 笔者 在 Github 上 的 开 
源 项 目 : https://github.com/singwhatiwanna/Pinned- 





HeaderExpandableListView. 
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到 这 里 ， 目 定义 View 相 关 的 知识 都 已 经 介绍 完了 ， 可 能 读者 还 是 沉 
得 有 点 模糊 。 前 面 说 过 ， 自 定义 View 是 一 个 综合 的 技术 体系 ， 很 多 情况 
下 需要 灵活 地 分 析 从 而 找 出 最 高 效 的 方法 ， 因 此 本 音 不 可 能 去 分 析 一 个 
个 具体 的 目 定义 View 的 实现 ， 因 为 目 定 义 View 五 化 八 门 ， 是 不 可 能 
部 分 析 一 过 的 。 虽 然 我 们 不 能 把 自 定 义 View 都 分 析 一 过 ， 但 是 我 们 能 够 
提取 出 一 种 思想 ， 在 面 对 陌 生 的 目 定 义 View 时 ， 运 用 这 个 思想 去 快速 地 
解决 问题 。 这 种 思想 的 描述 如 下 : 首先 要 掌握 基本 功 ， 比 如 View 的 弹性 
滑动 、 滑 动 冲 突 、 绘 制 原理 等 ， 这 些 东 西 者 是 自 定 义 View 所 必须 的 ， 尤 
其 是 那些 看 起 来 很 炫 的 自 定 义 View， 它 们 往往 对 这 些 技术 点 的 要 求 更 
高 ， 见 练 掌握 基本 功 以 后 ， 在 面 对 新 的 目 定 义 View 时 ， 要 能 够 对 其 分 类 
并 选择 合适 的 实现 思路 ， 自 定义 View 的 实现 方法 的 分 类 在 4.4.1 节 中 已 经 
介绍 过 了 ; 另外 平时 还 需要 多 积累 一 些 目 定 义 View 相 关 的 经 验 ， 并 逐渐 
做 到 融会 贯通， 通过 这 种 思想 慢 慢 地 就 可 以 提高 目 定义 View 的 水 平 了 。 




















第 5 草 ”理解 RemoteViews 


本 章 所 讲述 的 主题 是 RemoteViews， 从 名 字 可 以 看 出 ， 
RemoteViews 应 该 是 一 种 远程 View， 那 么 什么 是 远程 View 呢 ?如 果 说 远 
程 服务 可 能 比较 好 理解 ， 但 是 远程 View 的 确 没 听 说 过 ， 其 实 它 和 远程 
Service 是 一 样 的 ，RemoteViews 表 示 的 是 一 个 View 结 构 ， 它 可 以 在 其 他 
进程 中 显示 ， 由 于 它 在 其 他 进程 中 显示 ， 为 了 能 够 更 新 它 的 界面 ， 
RemoteViews 提 供 了 一 组 基础 的 操作 用 于 路 进程 更 新 它 的 界面 。 这 上 听 起 
来 有 点 神奇 ， 竟 然 能 路 进程 更 新 界面 ! 但 是 RemoteViews 的 确 能 够 实现 
这 个 效果 。RemoteViews 在 Android 中 的 使 用 场景 有 两 种 : 通知 栏 和 加 面 
小 部 件 ， 为 了 更 好 地 分 析 RemoteViews 的 内 部 机 制 ， 本 章 先 简单 介绍 
RemoteViews 在 通知 栏 和 吕 面 小 部 件 上 的 应 用 ， 接 着 分 析 RemoteViews 
的 内 部 机 制 ， 最 后 分 析 RemoteViews 的 意义 并 给 出 一 个 采用 
RemoteViews 来 路 进程 更 新 界面 的 示例 。 














5.1 RemoteViews 的 应 用 


RemoteViews 在 实际 开发 中 ， 主 要 用 在 通知 栏 和 蝎 面 小 部 件 的 开发 
过 程 中 。 通 知 栏 每 个 人 都 不 陌生 ， 主 要 是 通过 NotificationManager 的 
notify 方 法 来 实现 的 ， 它 除了 默认 效果 外 ， 还 可 以 男 外 定义 布局 。 泉 面 
小 部 件 则 是 通过 AppWidgetProvider 来 实现 的 ，AppWidget-Provider 本 质 
上 是 一 个 广播 。 通知 栏 和 时 面 小 部 件 的 开发 过 程 中 都 会 用 到 
RemoteViews， 它 们 在 更 新 界面 时 无 法 像 在 Activity 里 面 那样 去 直接 更 新 
View， 这 是 因为 二 者 的 界面 都 运行 在 其 他 进程 中 ， 确 切 来 说 是 系统 的 
SystemServer 进 程 。 为 了 跨 进 程 更 新 界面 ，RemoteViews 提 供 了 一 系列 
Set 方法， 并且 这 些 方法 只 是 View 全 部 方法 的 子 集 ， 另 外 RemoteViews 中 
所 文 持 的 View 类 型 也 是 有 限 的 ， 这 一 点 会 在 5.2 节 中 进行 详细 说 明 。 下 
面 简单 介绍 一 下 RemoteViews 在 通知 栏 和 时 面 小 部 件 中 的 使 用 方法 ， 至 
于 它们 更 详细 的 使 用 方法 请 读者 阅读 相关 资料 即 可 ， 本 章 的 重点 是 分 析 
RemoteViews 的 内 部 机 制 。 


5.1.1 RemoteViews 在 通知 栏 上 的 应 
用 


首先 我 们 看 一 下 RemoteViews 在 通知 栏 上 的 应 用 ， 我 们 知道 ， 通 知 
栏 除 了 默认 的 效果 外 还 支持 自 定 义 布局 ， 下 面 分 别 说 明 这 两 种 情况 。 








使 用 系统 默认 的 样式 弹出 一 个 通知 是 很 简单 的 ， 代 码 如 下 : 


Notification notification = new Notification(); 


notification.icon = R.drawable.ic_launcher; 

notification.tickerText = "hello world"; 

notification.when = System.currentTimeMillis(); 

notification.flags = Notification.FLAG_AUTO_CANCEL; 

Intent intent = new Intent(this, DemoActivity_1.class); 

PendingIntent pendingIntent = PendingIntent.getActivity(this, 

0, intent, PendingIntent .FLAG_UPDATE_CURRENT ) ; 

notification.setLatestEventiInfo(this,"chapter_5","this is not 

pendingIntent ); 

NotificationManager manager = (NotificationManager )getSystemS 
(Context .NOTIFICATION_SERVICE); 


manager .notify(1,notification) ; 


上 述 代码 会 弹出 一 个 系统 默认 样式 的 通知 ， 单 击 通 知 后 会 打开 
DemoActivity_1 同 时 会 清除 本 身 。 为 了 满足 个 性 化 需求 ， 我 们 还 可 能 会 
用 到 自 定 义 通 知 。 自 定义 通知 也 很 简单 ， 首 先 我 们 要 提供 一 个 布局 文 
件 ， 然 后 通过 RemoteViews 来 加 载 这 个 布局 文件 即 可 改变 通知 的 样式 ， 
代码 如 下 所 示 。 


Notification notification = new Notification(); 

notification.icon = R.drawable.ic_launcher; 

notification.tickerText = "hello world"; 

notification.when = System.currentTimeMillis(); 

notification.flags = Notification.FLAG_AUTO_CANCEL; 

Intent intent = new Intent(this, DemoActivity_1.class); 

PendingIntent pendingIntent = PendingIntent.getActivity(this, 
0, intent, PendingIntent .FLAG_UPDATE_CURRENT ) ; 


RemoteViews remoteViews = new RemoteViews(getPackageName(),R. 
layout_notification); 
remoteViews.setTextViewText(R.id.msg, "chapter_5"); 
remoteViews.setImageViewResource(R.id.icon,R.drawable.icon1); 
PendingIntent openActivity2PendingIntent = PendingIntent.getA 
0,new Intent(this, DemoActivity_2.class),PendingIn 
UPDATE_CURRENT ) ; 
remoteViews.setOnClickPendingIntent(R.id.open_activity2, openA 
PendingIntent ); 
notification.contentView = remoteViews; 
notification.contentIntent = pendingIntent; 
NotificationManager manager = (NotificationManager )getSystemS 
(Context .NOTIFICATION_SERVICE) ; 


manager .notify(2,notification) ; 


从 上 述 内 容 来 看 ， 目 定义 通知 的 效果 需要 用 到 RemoteViews， 和 上 自 定 
义 通知 的 效果 如 图 5-1 所 示 。 
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图 5-1 自 定义 通知 栏 样式 





RemoteViews 的 使 用 也 很 简单 ， 只 要 提供 当前 应 用 的 包 名 和 布局 文 
件 的 资源 id 即 可 创建 一 个 RemoteViews 对 象 。 如 何 更 新 RemoteViews 呢 ? 
这 一 点 和 更 新 View 有 很 大 的 不 同 ， 更 新 RemoteViews 时 ， 无 法 直接 访问 
里 面 的 View， 而 必须 通过 RemoteViews 所 提供 的 一 系列 方法 来 更 新 
View。 比 如 设置 TextView 的 文本 ， 要 采用 如 下 方式 : 
remoteViews.setTextViewText(R.id.msg,"chapter_5")， 其 中 
setTextViewText 的 两 个 参数 分 别 为 TextView 的 id 和 要 设置 的 文本 。 而 设 
置 ImageView 的 图 片 也 不 能 直接 访问 ImageView， 必 须 通 过 如 下 方式 : 
remoteViews.setImageViewResource(R.id.icon,R.drawable.icon1), 
setImageViewResource 的 两 个 参数 分 别 为 ImageView 的 id 和 要 设置 的 图 片 
资源 的 id。 如 果 要 给 一 个 控件 加 单 击 事件 ， 则 要 使 用 PendingIntent 并 通 


过 setOnClickPendingIntent 方 法 来 实现 ， 比 如 

remote Views.setOnClickPendingIntent(R.id.open_activity2,openActivity2Per 
Intenb 这 名 代码 会 给 id 为 open_activity2 的 View 加 上 单 击 事件 。 关 于 
PendingIntent， 它 表示 的 是 一 种 待定 的 Intent， 这 个 Intent 中 所 包含 的 意 
图 必须 由 用 户 来 触发 。 为 什么 更 新 RemoteViews 如 此 复杂 呢 ? 直观 原 
是 因为 RemoteViews 并 没有 提供 和 View 类 似 的 findViewById 这 个 方法 ， 

此 我 们 无 法 获取 到 RemoteViews 中 的 子 View， 当 然 实际 原因 绝 非 如 

此 ， 具 体会 在 5.2 节 中 进行 详细 介绍 。 


5.1.2 ”RemoteViews 在 桌面 小 部 件 上 
的 应 用 


AppWidgetProvider 是 Android 中 提供 的 用 于 实现 桌面 小 部 件 的 类 ， 
其 本 质 是 一 个 广播 ， 即 BroadcastReceiver， 图 5-2 所 示 的 是 它 的 类 继承 关 
系 。 所 以 ， 在 实际 的 使 用 中 ， 把 AppWidgetProvider 当 成 一 个 
BroadcastReceiver 就 可 以 了 ， 这 样 许多 功能 束 很 好 理解 了 。 


AppWidgetProvider -android.appwidget 
¥@ Object 
v ©* BroadcastReceiver 


‘© AppWidgetProvider 





图 5-2 AppWidgetProvider 的 类 继承 关系 





为 了 更 好 地 展示 RemoteViews 在 昌 面 小 部 件 上 的 应 用 ， 我 们 先 简 单 
介绍 桌面 小 部 件 的 开发 步骤 ， 分 为 如 下 几 步 。 


1. 定义 小 部 件 界面 


在 res/layout/ 下 新 建 一 个 XML 文 件 ， 命 名 为 widget.xml， 名 称 和 内 容 
可 以 自 定义 ， 看 这 个 小 部 件 要 做 成 什么 样子 ， 内 容 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/r 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android:orientation="vertical" > 
<ImageView 
android: id="@+id/imageView1" 
android: Layout_width="wrap_content" 
android: Layout_height="wrap_content" 
android: src="@drawable/iconi" /> 


</LinearLayout> 


2. 定义 小 部 件 配置 信息 


在 res/xml/ 下 新 建 appwidget_provider_info.xml， 名 称 随意 选择 ， 添 
加 如 下 内 容 : 


<?xml version="1.0" encoding="utf-8"?> 

<appwidget-provider xmlns:android="http://schemas.android.com 
android: initialLayout="@layout/widget" 
android:minHeight="84dp" 
android: minwidth="84dp" 
android: updatePeriodMillis="86400000" > 


</appwidget -provider> 


上 面 几 个 参数 的 意义 很 明确 ，initialLayout 就 是 指 小 工具 所 使 用 的 初 
始 化 布局 ，minHeight 和 minWidth 定 义 小 工具 的 最 小 尺寸 ， 
updatePeriodMillis 定 义 小 工具 的 自动 更 新 周期 ， 军 秒 为 单位 ， 每 隔 一 个 
周期 ， 小 工具 的 自动 更 新 就 会 触发 。 








3. 定义 小 部 件 的 实现 类 
这 个 类 需要 继承 AppWidgetProvider， 代 码 如 下 : 


public class MyAppWidgetProvider extends AppWidgetProvider { 
public static final String TAG = "MyAppWidgetProvider"; 
public static final String CLICK_ACTION = "com.ryg.chapt 
CLICK"; 
public MyAppWidgetProvider() { 
super(); 
J 
@Override 
public void onReceive(final Context context,Intent inten 


super .onReceive(context, intent); 








Log.i(TAG, "onReceive : action = " + intent.getAction 
// 这 里 判断 是 自己 的 action， 做 自己 的 事情 ， 比 如 小 部 件 被 单 击 了 要 
一 个 动画 效果 


if (intent.getAction().equals(CLICK_ACTION)) { 
Toast.makeText(context, "clicked it", Toast .LENGTH 
new Thread(new Runnable() { 


@Override 








Intent intentClick = new Intent(); 


intentClick.setAction(CLICK_ACTION); 


PendingIntent pendingIntent = PendingIntent.getBroad 


intentClick,0); 


remoteViews.setOnClickPendingIntent(R.id.imageView1, 


appWidgeManger . updateAppWidget (appwWidgetId, remoteVie’ 


private Bitmap rotateBitmap(Context context,Bitmap srcbB 


} 

degree) { 
Matrix 
matrix. 
matrix. 
Bitmap 
return 

} 


matrix = new Matrix(); 

reset(); 

setRotate(degree); 

tmpBitmap = Bitmap.createBitmap(srcbBitmap, 0, 
srcbBitmap.getwidth(),srcbBitmap.getHeight() 


tmpBitmap; 


上 面 的 代码 实现 了 一 个 简单 的 加 面 小 部 件 ， 在 小 部 件 上 面 显 示 一 张 
图 片 ， 单 击 它 后 ， 这 个 图 片 就 会 旋转 一 周 。 当 小 部 件 被 添加 到 架 面 后 ， 
会 通过 RemoteViews 来 加 载 布 局 文件 ， 而 当 小 部 件 被 单 击 后 的 旋转 效果 
则 是 通过 不 断 地 更 新 RemoteViews 来 实现 的 ， 由 此 可 见 ， 架 面 小 部 件 不 
管 是 初始 化 界面 还 是 后 续 的 更 新 界面 都 必须 使 用 RemoteViews 来 完成 。 





4. 在 AndroidManifest.xml 中 声明 小 部 件 





这 是 最 后 一 步 ， 因 为 果 面 小 部 件 本 质 上 是 一 个 广播 组 件 ， 因 此 必须 


要 注册 ， 如 下 所 示 。 


<receiver 
android:name=".MyAppWidgetProvider" > 
<meta-data 
android: name="android.appwidget.provider" 
android: resource="@xml/appwidget_provider_info"> 
</meta-data> 
<intent-filter> 
<action android:name="com.ryg.chapter_5.action.CL 
<action android:name="android.appwidget.action.AP 
</intent-filter> 


</receiver> 


上 面 的 代码 中 有 两 个 Action， 其 中 第 一 个 Action 用 于 识别 小 部 件 的 
单 击 行为 ， 而 第 二 个 Action 则 作为 小 部 件 的 标识 而 必须 存在 ， 这 是 系统 
的 规范 ， 如 果 不 加 ， 那 么 这 个 receiver 就 不 是 一 个 桌面 小 部 件 并 且 也 无 
法 出 现在 手机 的 小 部 件 列 表 里 。 





AppWidgetProvider 除 了 最 常用 的 onUpdate 方 法 ， 还 有 其 他 几 个 方 
法 : onEnabled、onDisabled、onDeleted 以 及 onReceive。 这 些 方法 会 自动 
地 被 onReceive 方 法 在 合适 的 时 间 调 用 。 确 切 来 说 ， 当 广播 到 来 以 后 ， 
AppWidgetProvider 会 自动 根据 广播 的 Action 通 过 onReceive 方 法 来 自动 分 
发 广播 ， 也 束 是 调用 上 述 几 个 方法 。 这 几 个 方法 的 调用 时 机 如 下 所 示 。 


e onEnable: 当 该 窗口 小 部 件 第 一 次 添加 到 加 面 时 调用 该 方法 ， 可 添 
加 多 次 但 只 在 第 一 次 调用 。 

e onUpdate: 小 部 件 被 添加 时 或 者 每 次 小 部 件 更 新 时 都 会 调用 一 次 该 
方法 ， 小 部 件 的 更 新 时 机 由 updatePeriodMillis 来 指定 ， 每 个 周期 小 
部 件 都 会 自动 更 新 一 次 。 


。 onDeleted: # Mtb —KKM/Dab Pata i 

e onDisabled: 当 最 后 一 个 该 类 型 的 更 面 小 部 件 被 删除 时 调用 访 方 
法 ， 注 意 是 最 后 一 个 。 

e onReceive: 这 是 广播 的 内 置 方法 ， 用 于 分 发 具体 的 事件 给 其 他 方 


关于 AppWidgetProvider 的 onReceive 方 法 的 具体 分 发 过 程 ， 可 以 参 
看 源码 中 的 实现 ， 如 下 所 示 。 通 过 下 面 的 代码 可 以 看 出 ，onReceive 中 
会 根据 不 同 的 Action 来 分 别 调用 onEnable、onDisable 和 onUpdate 等 方 
rae 


public void onReceive(Context context,Intent intent) { 
// Protect against rogue update broadcasts (not really a 
// just filter bad broacasts out so subclasses are less 1 
String action = intent.getAction(); 
if (AppWidgetManager .ACTION_APPWIDGET_UPDATE.equals(actio 
Bundle extras = intent.getExtras(); 
if (extras != null) { 
int[] appWidgetIds = extras.getiIntArray(A 
EXTRA_APPWIDGET_IDS); 
if (appWidgetIds != null && appWidgetIds. 
this.onUpdate(context, AppWwidgetMa 
(context),appWidgetIds); 


} 
} else if (AppWidgetManager .ACTION_APPWIDGET_DELETED. equa 


Bundle extras = intent.getExtras(); 


if (extras != null && extras.containsKey(AppWidge 
APPWIDGET_ID)) { 
final int appWidgetId = extras.getInt(App 
APPWIDGET_ID); 
this.onDeleted(context,new int[] { appWid 
} 
} else if (AppwidgetManager .ACTION_APPWIDGET_OPTIONS_CHAN 
(action)) { 
Bundle extras = intent.getExtras(); 
if (extras != null && extras.containsKey(AppWidge 
APPWIDGET_ID) 
&& extras.containsKey(AppWidgetMa 
OPTIONS)) { 
int appWidgetId = extras.getInt(AppWidget 
APPWIDGET_ID); 
Bundle widgetExtras = extras.getBundle(Ap 
APPWIDGET_OPTIONS ) ; 
this .onAppWidgetOptionsChanged(context, Ap 
getInstance(context), 
appWidgetId,widgetExtras) 
j; 
} else if (AppWidgetManager .ACTION_APPWIDGET_ENABLED.equa 
this.onEnabled(context); 
} else if (AppWidgetManager .ACTION_APPWIDGET_DISABLED. equ 
this.onDisabled(context); 
} else if (AppWidgetManager .ACTION_APPWIDGET_RESTORED. equ 


Bundle extras = intent.getExtras(); 


if (extras != null) { 

int[] oldIds = extras.getiIntArray(AppWidg 

APPWIDGET_OLD_IDS); 

int[] newIds = extras.getiIntArray(AppWidg 

APPWIDGET_IDS); 

if (oldIds != null && oldIds.length > 0) 
this.onRestored(context, oldIds, ne 
this.onUpdate(context, AppwidgetMa 


(context ),newlIds) ; 


} 


EER SIP AP DE Re, Ar eR, SKER 
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件 在 界面 上 的 操作 都 要 通过 Remote-Views， 不 管 是 小 部 件 的 界面 初始 化 
还 是 界面 更 新 都 必须 依赖 它 。 


5.1.3 PendingIntent# {ik 


在 5.1.2 节 中 ， 我 们 多 次 提 到 PendingIntent， 那 么 PendingIntent 到 底 
FEA AR GME? 它 和 Intent 的 区 别 是 什么 呢 ? 在 本 节 中 将 介绍 
PendingIntent 的 使 用 方法 。 


顾名思义 ，PendingIntent 表 示 一 种 处 于 pending 状 态 的 意图 ， 而 
pending 状 态 表 示 的 是 一 种 待定 、 等 待 、 即 将 发 生 的 意思 ， 吏 是 说 接 下 


来 有 一 个 Intent( 即 意图 ) 将 在 某 个 待定 的 时 刻 发 生 。 可 以 看 出 
PendingIntent 和 Intent 的 区 别 在 于 ，PendingIntent 是 在 将 来 的 某 个 不 m 定 
的 时 刻 发 生 ， 而 Intent 是 立刻 发 生 。PendingIntent 典 型 的 使 用 场景 是 给 
RemoteViews 添 加 单 击 事件 ， 因 为 RemoteViews 运 行 在 远程 进程 中 ， 因 
此 RemoteViews 不 同 于 普通 的 View， 所 以 无 法 直接 向 View 那 样 通过 
setOnClickListener 方 法 来 设置 单 击 事件 。 要 想 给 RemoteViews 设 置 单 击 
事件 ， 就 必须 使 用 PendingIntent，PendingIntent 通 过 send 和 cancel 方 法 来 
发 送 和 取消 特定 的 待定 Intent。 














PendingIntent 文 持 三 种 待定 意图 : 启动 Activity、 启 动 Service 和 发 送 
广播 ， 对 应 着 它 的 三 个 接口 方法 ， 如 表 5-1 所 示 。 








表 5-1 Pendinglntent 的 主要 方法 





getActivity(Context context, int requestCode, Intent 
intent, int flags) 


SEAR 人 ve fe pi $ : » 
PendingIntent oe 六 PendingIntent， 该 待定 意图 发 生 时 ， 效 果 相 


static 


Context.startActivity(Intent) 





getService(Context context, int requestCode, Intent 
intent, int flags) 


static SRI A A i x 
Ñ 村 ’ % > wy Jos x 
Povdinaincent oe 站 PendingIntent， 该 待定 意图 发 生 时 ， 效 果 相 


Context.startService(Intent) 





getBroadcast(Context context, int requestCode, Intent 
intent, int flags) 


static HUA A : iy fel os eS PS 
Dendinetatent 2 六 PendingIntent， 该 待定 意图 发 生 时 ， 效 果 相 


Context.sendBroadcast(Intent) 





如 表 5-1 所 示 ，getActivity、getService 和 getBroadcast 这 三 个 方法 的 
参数 意义 都 是 相同 的 ， 第 一 个 和 第 三 个 参数 比较 好 理解 ， 这 里 主要 说 下 
第 二 个 参数 requestCode 和 第 四 个 参数 flags， 其 中 requestCode 表 示 
PendingIntent 发 送 方 的 请 求 码 ， 多 数 情 况 下 设 为 0 即 可 ， 男 外 requestCode 
会 影响 到 flags 的 效果 。flags 常 见 的 类 型 有 : FLAG_ONE_SHOT、 
FLAG NO CREATE、 FLAG CANCEL CURRENT 和 
FLAG_UPDATE_CURRENT。 在 说 明 这 四 个 标记 位 之 前 ， 必 须要 明白 
一 个 概念 ， 那 束 是 PendingIntent 的 逻 配 规则 ， 即 在 什么 情况 下 两 个 
PendingIntent 是 相同 的 。 


PendingIntent 的 匹配 规则 为 : 如果 两 个 PendingIntent 它 们 内 部 的 
Intent 相 同 并 且 requestCode 也 相同 ， 那 么 这 两 个 PendingIntent 就 是 相同 
的 。requestCode 相 同比 较 好 理解 ， 那 么 什么 情况 下 Intent 相 同 呢 ? Intent 
的 匹配 规则 是 : 如 果 两 个 mtent 的 ComponentName 和 intent-filter 都 相同 ， 
那么 这 两 个 Intent 吏 是 相同 的 。 需 要 注意 的 是 Extras 不 参与 Intent 的 匹配 
过 程 ， 只 要 Intent 之 间 的 ComponentName 和 intent-filter 相 同 ， 即 使 它们 的 
Extras 不 同 ， 那 么 这 两 个 Intent 也 是 相同 的 。 了 解 了 PendingIntent 的 匹配 
规则 后 ， 就 可 以 进一步 理解 fags 参 数 的 含义 了 ， 如 下 所 示 。 


FLAG_ONE_SHOT 


当前 描述 的 PendingIntent 只 能 被 使 用 一 次 ， 然 后 它 就 会 被 自动 
cancel， 如 果 后 续 还 有 相同 的 PendingIntent， 那 么 它们 的 send 方 法 就 会 调 
用 失败 。 对 于 通知 栏 消息 来 说 ， 如 果 采 用 此 标记 位 ， 那 么 同类 的 通知 只 
能 使 用 一 次 ， 后 续 的 通知 单 击 后 将 无 法 打开 。 


FLAG_NO_CREATE 


当前 描述 的 PendingIntent 不 会 主动 创建 ， 如 果 当 前 PendingIntent 之 
前 不 存在 ， 那 么 getActivity、getService 和 getBroadcast 方 法 会 直接 返回 
null， 即 获取 PendingIntent 失 败 。 这 个 标记 位 很 少见 ， 它 无 法 单独 使 用 ， 
因此 在 日 常 开 发 中 它 并 没有 太 多 的 使 用 意义 ， 这 里 就 不 再 过 多 介绍 了 。 











FLAG_CANCEL_CURRENT 


当前 描述 的 PendingIntent 如 果 已 经 存在 ， 那 么 它们 都 会 被 cancel， 然 
后 系统 会 创建 一 个 新 的 PendingIntent。 对 于 通知 栏 消息 来 说 ， 那 些 被 
cancel 的 消息 单 击 后 将 无 法 打开 。 


FLAG_UPDATE_CURRENT 


当前 描述 的 PendingIntent 如 果 已 经 存在 ， 那 么 它们 都 会 被 更 新 ， 即 
它们 的 Intent 中 的 Extras 会 被 蔡 换 成 最 新 的 。 


从 上 面 的 分 析 来 看 还 是 不 太 好 理解 这 四 个 标记 位 ， 下 面 结合 通知 栏 
消息 再 描述 一 各。 这 里 分 两 种 情况 ， 如 下 代码 中 : 
manager.notify(1,notification)， 如 果 notify 的 第 一 个 参数 id 是 和 常量， 那么 
多 次 调用 notify 只 能 弹出 一 个 通知 ， 后 续 的 通知 会 把 前 面 的 通知 完全 蔡 
代 控 ， 而 如 果 每 次 id 剖 不同， 那么 多 次 调用 notify 会 弹出 多 个 通知 ， 下 面 
一 一 说 明 。 





如 果 notify 方 法 的 id 是 常量 ， 那 么 不 管 PendingIntent 是 否 匹 配 ， 后 面 
的 通知 会 直接 蔡 换 前 面 的 通知 ， 这 个 很 好 理解 。 


如 末 notify 方 法 的 id 每 次 都 不 同 ， 那 么 当 PendingIntent 不 匹配 时 ， 这 
里 的 匹配 是 指 PendingIntent 中 的 Intent 相 同 并 且 requestCode 相 同 ， 在 这 种 
情况 下 不 管 采用 何 种 标记 位 ， 这 些 通知 之 间 不 会 相互 干扰 。 如 果 











PendingIntent 处 于 匹配 状态 时 ， 这 个 时 候 要 分 情况 讨论 : 如 果 采 用 了 
FLAG_ONE_SHOT 标 记 位 ， 那 么 后 续 通 知 中 的 PendingIntent 会 和 第 一 条 
通知 保持 完全 一 致 ， 包 括 其 中 的 Extras， 单 击 任何 一 条 通知 后 ， 剩 下 的 
通知 均 无 法 再 打开 ， 当 所 有 的 通知 都 被 清除 后 ， 会 再 次 重复 这 个 过 程 ; 
如 果 采 用 FLAG_CANCEL_CURRENT 标 记 位 ， 那 么 只 有 最 新 的 通知 可 
以 打开 ， 之 前 弹出 的 所 有 通知 均 无 法 打开 ; 如 果 采 用 
FLAG_UPDATE_CURRENT 标 记 位 ， 那 么 之 前 弹出 的 通知 中 的 
PendingImtent 会 被 更 新 ， 最 终 它们 和 最 新 的 一 条 通知 保持 完全 一 致 ， 包 
括 其 中 的 Extras， 并 且 这 些 通知 都 是 可 以 打开 的 。 





5.2 RemoteViews 的 内 部 机 制 





RemoteViews 的 作用 是 在 其 他 进程 中 显示 并 更 新 View 界 面 ， 为 了 更 
好 地 理解 它 的 内 部 机 制 ， 我 们 先 来 看 一 下 它 的 主要 功能 。 首 先 看 一 下 它 
的 构造 方法 ， 这 里 只 介绍 一 个 最 常用 的 构造 方法 : public 
RemoteViews(String packageName,int layoutId)， 它 接受 两 个 参数 ， 第 一 
个 表示 当前 应 用 的 包 名 ， 第 二 个 参数 表示 符 加 载 的 布局 文件 ， 这 个 很 好 
理解 。RemoteViews 目 前 并 不 能 文 持 所 有 的 View 类 型 ， 它 所 文 持 的 所 有 
类 型 如 下 : 








Layout 
FrameLayout、LinearLayout、RelativeLayout、GridLayout。 
View 


AnalogClock, Button. Chronometer, ImageButton. ImageView, 
ProgressBar. TextView. ViewFlipper, ListView. GridView, 
StackView. AdapterViewFlipper. ViewStub. 


上 面 所 描述 的 是 RemoteViews 所 支持 的 所 有 的 View 类 型 ， 
RemoteViews 不 文 持 它们 的 子 类 以 及 其 他 View 类 型 ， 也 就 是 说 
RemoteViews 中 不 能 使 用 除了 上 述 列 表 中 以 外 的 View， 也 无 法 使 用 自 定 
义 View。 比 如 如 果 我 们 在 通知 栏 的 RemoteViews 中 使 用 系统 的 
EditText， 那 么 通知 栏 消 筷 将 无 法 弹出 并 且 会 抛 出 如 下 异常 : 


E/StatusBar(765): couldn't inflate view for notification com. 


5/0x2 

E/StatusBar(765): android.view.InflateException: Binary XML f 

Error inflating class android.widget.EditText 

E/StatusBar(765): Caused by: android.view.InflateException: B 

line #25: Class not allowed to be inflated android.widget.Edi 

E/StatusBar (765): at android.view.LayoutInflater.failNotA 
(LayoutInflater.java:695) 

E/StatusBar (765): at android.view.LayoutInflater.createVi 
(LayoutInflater.java:628) 

E/StatusBar (765): ... 21 more 


上 面 的 异常 信息 很 明确 ，android.widget.EditText 不 允许 在 
RemoteViews 中 使 用 。 





RemoteViews 没 有 提供 findViewById 方 法 ， 因 此 无 法 直接 访问 里 面 
的 View 元 素 ， 而 必须 通过 RemoteViews 所 提供 的 一 系列 set 方 法 来 完成 ， 
当然 这 是 因为 RemoteViews 在 远程 进程 中 显示 ， 所 以 没 办 法 直接 
findViewById。 表 5-2 列 举 了 部 分 第 用 的 set 方 法 ， 更 多 的 方法 请 但 看 相 





表 5-2 RemoteViews 的 部 分 set 方 法 


setTextViewText(int viewId, CharSequence text) 设置 TextView 的 文本 





setTextViewTextSize(int viewld, int units, float size) 设置 TextView 的 字体 大 小 





setTextColor(int viewld, int color) 设置 TextView 的 字体 颜色 





setImageViewResource(int viewId, int srcId) 设置 Image View 的 图 片 资源 





setImageViewResource 设置 ImageView 的 图 片 


setInt(int viewld, String methodName, int value) 反射 调用 View 对 象 的 参数 类 型 为 int 的 方法 





setLong(int viewld, String methodName, long value) 反射 调用 View X 类 型 为 long 的 方法 








setBoolean(int viewld, String methodName, boolean value) 反射 调用 View 对 和 象 的 参数 类 型 为 boolean 的 方法 











setOnClickPendingIntent(int viewId, PendingIntent pendingIntent) | 为 View 添加 单 击 事件 ， 事 件 类 型 只 能 为 PendingIntent 


从 表 5-2 中 可 以 看 出 ， 原 本 可 以 直接 调用 的 View 的 方法 ， 现 在 却 必 
须要 通过 RemoteViews 的 一 系列 set 方 法 才能 完成 ， 而 且 从 方法 的 声明 上 
来 看 ， 很 像 是 通过 反射 来 完成 的 ， 事 实 上 大 部 分 set 方 法 的 确 是 通过 反射 
来 完成 的 。 





下 面 描述 一 下 RemoteViews 的 内 部 机 制 ， 由 于 RemoteViews 主 要 用 
于 通知 栏 和 加 面 小 部 件 之 中 ， 这 里 就 通过 它们 来 分 析 RemoteViews 的 工 
作 过 程 。 我 们 知道 ， 通 知 栏 和 揭 面 小 部 件 分 别 由 NotificationManager 和 
AppWidgetManager 管 理 ， 而 NotificationManager 和 AppWidgetManager 通 
过 Binder 分 别 和 SystemServer 进 程 中 的 NotificationManagerService 以 及 
AppWidgetService 进 行 通信 。 由 此 可 见 ， 通 知 栏 和 桌面 小 部 件 中 的 布局 
文件 实际 上 是 在 NotificationManagerService 以 及 AppWidgetService 中 被 加 
载 的 ， 而 它们 运行 在 系统 的 SystemServer 中 ， 这 就 和 我 们 的 进程 构成 了 
跨 进 程 通信 的 场景 。 





首先 RemoteViews 会 通过 Binder 传 递 到 SystemServer 进 程 ， 这 是 因为 
RemoteViews 实 现 了 Parcelable 接 口 ， 因 此 它 可 以 路 进程 传输 ， 系 统 会 根 
据 RemoteViews 中 的 包 名 等 信息 去 得 到 该 应 用 的 资源 。 然 后 会 通过 
LayoutInflater 去 加 载 RemoteViews 中 的 布局 文件 。 在 SystemServer 进 程 中 
加 载 后 的 布局 文件 是 一 个 普通 的 View， 只 不 过 相对 于 我 们 的 进程 它 是 一 
个 RemoteViews 而 已 。 接 着 系统 会 对 View 执 行 一 系列 界面 更 新 任务 ， 这 
些 任务 就 是 之 前 我 们 通过 set 方 法 来 提交 的 。set 方 法 对 View 所 做 的 更 新 
并 不 是 立刻 执行 的 ， 在 RemoteViews 内 部 会 记录 所 有 的 更 新 操作 ， 有 具体 
的 执行 时 机 要 等 到 RemoteViews 被 加 载 以 后 才能 执行 ， 这 样 
RemoteViews 就 可 以 在 SystemServer 进 程 中 显示 了 ， 这 就 是 我 们 所 看 到 
的 通知 栏 消息 或 者 昌 面 小 部 件 。 当 需要 更 新 RemoteViews 时 ， 我 们 需要 
调用 一 系列 set 方 法 并 通过 NotificationManager 和 AppWidgetManager 来 提 














区 更 新 任务 ， 有 具体 的 更 新 操作 也 是 在 SystemServerj 进 程 中 完成 的 。 


从 理论 上 来 说 ， 系 统 完全 可 以 通过 Binder 去 支持 所 有 的 View 和 View 
操作 ， 但 是 这 样 做 的 话 代 价 太 大 ， 因 为 View 的 方法 太 多 了 ， 男 外 束 是 大 
量 的 了 PC 操作 会 影响 效率 。 为 了 解决 这 个 问题 ， 系 统 并 没有 通过 Binder 
去 直接 文 持 View 的 路 进程 访问 ， 而 是 提供 了 一 个 Action 的 概念 ，Action 
代表 一 个 View 操 作 ，Action 同 样 实现 了 Parcelable 接 口 。 系 统 首先 将 
View 操 作 封装 到 Action 对 象 并 将 这 些 对 象 跨 进 程 传 输 到 远程 进程 ， 接 着 
在 远程 进程 中 执行 Action 对 象 中 的 具体 操作 。 在 我 们 的 应 用 中 每 调用 一 
次 set 方 法 ，RemoteViews 中 就 会 添加 一 个 对 应 的 Action 对 象 ， 当 我 们 通 
过 NotificationManager 和 AppWidgetManager 来 提交 我 们 的 更 新 时 ， 这 些 
Action 对 象 就 会 传输 到 远程 进程 并 在 远程 进程 中 依次 执行 ， 这 个 过 程 可 
以 参看 图 5-3。 远 程 进 程 通 过 RemoteViews 的 apply 方 法 来 进行 View 的 更 
新 操作 ，RemoteViews 的 apply 方 法 内 部 则 会 去 轴 历 所 有 的 Action 对 象 并 
调用 它们 的 apply 方 法 ， 具 体 的 View 更 新 操作 是 由 Action 对 象 的 apply 方 
法 来 完成 的 。 上 述 做 法 的 好 处 是 显而易见 的 ， 首 先 不 需要 定义 大 量 的 
Binder 接 口 ， 其 次 通过 在 远程 进程 中 批量 执行 RemoteViews 的 修改 操作 
从 而 避免 了 大 量 的 IPC 操 作 ， 这 就 提高 了 程序 的 性 能 ， 由 此 可 见 ， 
Android 系 统 在 这 方面 的 设计 的 确 很 精妙 。 

















RemoteViews | | RemoteViews | 


图 5-3 RemoteViews 的 内 部 机 制 


上 面 从 理论 上 分 析 了 RemoteViews 的 内 部 机 制 ， 接 下 来 我 们 从 源码 
的 角度 再 来 分 析 RemoteViews 的 工作 流程 。 它 的 构造 方法 就 不 用 多 说 
了 ， 这 里 我 们 首先 看 一 下 它 提供 的 一 系列 set 方 法 ， 比 如 setTextViewText 
方法 ， 其 源码 如 下 所 示 。 





public void setTextViewText(int viewId,CharSequence text) { 


setCharSequence(viewId, "setText", text); 


} 


在 上 面 的 代码 中 ，viewId 是 被 操作 的 View 的 id, “setText” 是 方法 
名 ，text 是 要 给 TextView 设 置 的 文本 ， 这 里 可 以 联想 一 下 TextView 的 
setText 方 法 ， 是 不 是 很 一 致 呢 ? 接 着 再 看 setCharSequence 的 实现 ， 如 下 
所 示 。 


public void setCharSequence(int viewId,String methodName, Char 
value) { 
addAction(new ReflectionAction(viewId, methodName, Reflecti 


CHAR_SEQUENCE, value) ); 
上 


从 setCharSequence 的 实现 可 以 看 出 ， 它 的 内 部 并 没有 对 View 进 程 直 
接 的 操作 ， 而 是 添加 了 一 个 ReflectionAction 对 象 ， 从 名 字 来 看 ， 这 应 该 
是 一 个 反射 类 型 的 动作 。 再 看 addAction 的 实现 ， 如 下 所 示 。 





private void addAction(Action a) { 


if (mActions == null) { 


mActions = new ArrayList<action>(); 
} 
mActions.add(a); 
// update the memory usage stats 


a.updateMemoryUsageEstimate(mMemoryUsageCounter); 


从 上 述 代 码 可 以 知道 ，RemoteViews 内 部 有 一 个 mActions 成 员 ， 

是 一 个 ArrayList， 外 界 每 调用 一 次 set 方 法 ，RemoteViews 就 会 为 其 Je 
一 个 Action 对 象 并 加 入 到 这 个 ArrayList 中 。 需 要 注意 的 是 ， 这 里 仪 仪 是 
将 Action 对 象 保存 起 来 了 ， 并 未 对 View 进 行 实际 的 操作 ， 这 一 点 在 上 面 
的 理论 分 析 中 已 经 提 到 过 了 。 到 这 里 setTextViewText 这 个 方法 的 源码 已 
经 分 析 完 了 ， 但 是 我 们 好 像 还 是 什么 都 不 知道 的 感觉 ， 没 关系 ， 接 着 我 
们 需要 看 一 下 这 个 ReflectionAction 的 实现 就 知道 了 。 再 看 它 的 实现 之 

前 ， 我 们 需要 先 看 一 下 RemoteViews 的 apply 方 法 以 及 Action 类 的 实现 ， 
首先 看 一 下 RemoteViews 的 apply 方 法 ， 如 下 所 示 。 





public View apply(Context context,ViewGroup parent, OnClickHan 
RemoteViews rvToApply = getRemoteViewsToApply(context); 


View result; 


LayoutInflater inflater = (LayoutInflater ) 
context.getSystemService(Context.LAYOUT_I 
// Clone inflater so we load resources from correct conte 
// we don't add a filter to the static version returned b 
Service. 


inflater = inflater.cloneInContext(inflationContext); 


inflater.setFilter(this); 
result = inflater.inflate(rvToApply.getLayoutId(),parent, 
rvToApply.performApply(result, parent, handler); 


return result; 


} 


从 上 面 代 码 可 以 看 出 ， 首 先 会 通过 LayoutInflater 去 加 载 
RemoteViews 中 的 布局 文件 ，RemoteViews 中 的 布局 文件 可 以 通过 
getLayoutId 这 个 方法 获得 ， 加 载 完 布 局 文件 后 会 通过 performApply 去 执 
行 一 些 更 新 操作 ， 代 码 如 下 所 示 。 





private void performApply(View v,ViewGroup parent, OnClickHand 
if (mActions != null) { 
handler = handler == null ? DEFAULT_ON_CLICK_HAND 
final int count = mActions.size(); 
for (int i = 0; i < count; i++) { 
Action a = mActions.get(i); 


a.apply(v, parent, handler); 


} 





performApply Hy KILE Leper FH. E EH it Ae id Fm Actions 
这 个 列表 并 执行 每 个 Action 对 象 的 apply 方 法 。 还 记得 mAction 吗 ? 每 一 
次 的 set 操 作 都 会 对 应 着 它 里 面 的 一 个 Action 对 象 ， 因 此 我 们 可 以 断定 ， 
Action 对 象 的 apply 方 法 就 是 真正 操作 View 的 地 方 ， 实 际 上 的 确 如 此 。 








RemoteViews 在 通知 栏 和 吕 面 小 部 件 中 的 工作 过 程 和 上 和 面 描述 的 过 


程 是 一 致 的 ， 当 我 们 调用 RemoteViews 的 set 方 法 时 ， 并 不 会 立刻 更 新 它 
们 的 界面 ， 而 必须 要 通过 Notification-Manager 的 notify 方 法 以 及 
AppWidgetManager 的 updateAppWidget 才 能 更 新 它们 的 界面 。 实 际 上 在 
AppWidgetManager 的 updateAppWidget 的 内 部 实现 中 ， 它 们 的 确 是 通过 
RemoteViews 的 apply 以 及 reapply 方 法 来 加 载 或 者 更 新 界面 的 ，apply 和 
reApply 的 区 别 在 于 : apply 会 加 载 布局 并 更 新 界面 ， 而 reApply 则 只 会 更 
新 界面 。 通 知 栏 和 蝎 面 小 插件 在 初始 化 界面 时 会 调用 apply 方 法 ， 而 在 
后 续 的 更 新 界面 时 则 会 调用 reapply 方 法 。 这 里 先 看 一 下 BaseStatusBar 的 
updateNotificationViews 方 法 中 ， 如 下 所 示 。 














private void updateNotificationViews(NotificationData.Entry e 
StatusBarNotification notification,boolean isHead 
final RemoteViews contentView = notification.getNotificat 
contentView; 
final RemoteViews bigContentView = isHeadsUp 
? notification. getNotification( ).headsUpC 
: notification.getNotification().bigConte 
final Notification publicVersion = notification. getNotifi 
final RemoteViews publicContentView = publicVersion != nu 
// Reapply the RemoteViews 


contentView. reapply(mContext, entry.expanded, mOnClickHandl 


很 显然 ， 上 述 代 码 表示 当 通 知 栏 界 面 需要 更 新 时 ， 它 会 通过 
RemoteViews 的 reapply 方 法 来 更 新 界面 。 


接着 再 看 一 下 AppWidgetHostView 的 updateAppWidget 方 法 ， 在 它 的 


内 部 有 如 下 一 段 代码 : 


从 上 述 代 码 可 以 友 现 ， 果 面 小 部 件 在 更 新 界面 时 也 是 通过 





RemoteViews 的 reapply 方 法 来 实现 的 。 


了 解 了 apply 以 及 reapply 的 作用 以 后 ， 我 们 再 继续 看 一 些 Action 的 子 
类 的 具体 实现 ， 首 先 看 一 下 ReflectionAction 的 具体 实现 ， 它 的 源码 如 下 
所 示 。 





throw new ActionException(ex); 


通过 上 述 代码 可 以 发 现 ，ReflectionAction 表 示 的 是 一 个 反射 动作 ， 
通过 它 对 View 的 操作 会 以 反射 的 方式 来 调用 ， 其 中 getMethod 就 是 根据 
方法 名 来 得 到 反射 所 需 的 Method 对 象 。 使 用 ReflectionAction 的 Set 方法 
有 : setTextViewText、setBoolean、setLong、setDouble 等 。 除 了 
ReflectionAction， 还 有 其 他 Action， 比 如 TextViewSizeAction、 
ViewPaddingAction、SetOnClickPendingIntent 等 。 这 里 再 分 析 一 下 
TextViewSizeAction， 它 的 实现 如 下 所 示 。 


private class TextViewSizeAction extends Action { 
public TextViewSizeAction(int viewId,int units,float size 
this.viewId = viewId; 
this.units = units; 


this.size = size; 


@Override 

public void apply(View root,ViewGroup rootParent, OnClickH 
final TextView target = (TextView) root.findViewB 
if (target == null) return; 
target.setTextSize(units,size); 


} 
public String getActionName() { 


return "TextViewSizeAction"; 
} 
int units; 
float size; 


public final static int TAG = 13; 


TextViewSizeAction 的 实现 比较 简单 ， 它 之 所 以 不 用 反射 来 实现 ， 
是 因为 setTextSize 这 个 方法 有 2 个 参数 ， 因 此 无 法 复 用 ReflectionAction， 
为 ReflectionAction 的 反映 调 用 只 有 一 个 参数 。 其 他 Action 这 里 就 不 一 
一 进行 分 析 了 ， 读 者 可 以 查看 RemoteViews 的 源 代 人 码 。 





关于 单 击 事 件 ，RemoteViews 中 只 支持 发 起 PendingIntent， 不 支持 
onClickListener 那 种 模式 。 另 外 ， 我 们 需要 注意 
setOnClickPendingIntent、setPendingIntentTemplate 以 及 
setOnClickFillInIntent 它 们 之 间 的 区 别 和 联系 。 首 先 
setOnClickPendingIntent 用 于 给 普通 View 设 置 单 击 事 件 ， 但 是 不 能 给 集 
合 〈ListView 和 StackView) 中 的 View 设 置 单 击 事件 ， 比 如 我 们 不 能 给 
ListView 中 的 item 通 过 setOnClickPendingIntent 这 种 方式 添加 单 击 事件 ， 
因为 开销 比较 大 ， 所 以 系统 禁止 了 这 种 方式 ; 其 次 ， 如 果 要 给 ListView 
和 StackView 中 的 item 添 加 单 击 事件 ， 则 必须 将 setPendingIntentTemplate 
和 setOnClickFillInIntent 组 合 使 用 才 可 以 。 


5.3 RemoteViewst) = 


在 5.2 节 中 我 们 分 析 了 RemoteViews 的 内 部 机 制 ， 了 解 RemoteViews 
的 内 部 机 制 可 以 让 我 们 更 加 清楚 通知 栏 和 更 面 小 工具 的 底层 实现 原理 ， 
但 是 本 章 对 RemoteViews 的 探索 并 没有 停止 ， 在 本 节 中 ， 我 们 将 打造 一 
个 模拟 的 通知 栏 效果 并 实现 路 进程 的 UI 更 新 。 








首先 有 2 个 Activity 分 别 运 行 在 不 同 的 进程 中 ， 一 个 名 字 叫 A， 另 一 
个 叫 B， 其 中 人 A 扮演 着 模拟 通知 栏 的 角色 ， 而 B 则 可 以 不 停 地 发 送 通 知 栏 
消息 ， 当 然 这 是 模拟 的 消 恩 。 为 了 模拟 通知 栏 的 效果 ， 我 们 修改 A 的 
process 属 性 使 其 运行 在 单独 的 进程 中 ， 这 样 A 和 B 就 构成 了 多 进程 通信 
的 情形 。 我 们 在 B 中 创建 RemoteViews 对 象 ， 然 后 通知 A 显 示 这 个 
RemoteViews 对 象 。 如 何 通知 A 显 示 B 中 的 RemoteViews 呢 ? 我 们 可 以 像 
系统 一 样 采 用 Binder 来 实现 ， 但 是 这 里 为 了 简单 起 见 就 采用 了 广播 。B 
每 发 送 一 次 模拟 通知 ， 束 会 发 送 一 个 特定 的 广播 ， 然 后 A 接 收 到 广播 后 
就 开始 显示 B 中 定义 的 RemoteViews 对 象 ， 这 个 过 程 和 系统 的 通知 栏 消 
恩 的 显示 过 程 几乎 一 致 ， 或 者 说 这 里 就 是 复制 了 通知 栏 的 显示 过 程 而 
mae 

















首先 看 B 的 实现 ，B 只 要 构造 RemoteViews 对 象 并 将 其 传输 给 A 即 
可 ， 这 一 过 程 通 知 栏 是 采用 Binder 实 现 的 ， 但 是 本 例 中 采用 广播 来 实 
现 ，RemoteViews 对 象 通 过 Intent 传 输 到 A 中 ， 代 码 如 下 所 示 。 


RemoteViews remoteViews = new RemoteViews(getPackageName(),R. 
remoteViews.setTextViewText(R.id.msg, "msg from process:" + Pr 


remoteViews.setImageViewResource(R.id.icon,R.drawable.icon1); 


PendingIntent pendingIntent = PendingIntent.getActivity(this, 
0,new Intent(this, DemoActivity_1.class),PendingIn 
PendingIntent openActivity2PendingIntent = PendingIntent.getA 
this,0,new Intent(this, DemoActivity_2.class),Pend 
remoteViews.setOnClickPendingIntent(R.id.item_holder, pendingI 
remoteViews.setOnClickPendingIntent(R.id.open_activity2, openA 
Intent intent = new Intent(MyConstants.REMOTE_ACTION) ; 
intent. putExtra(MyConstants.EXTRA_REMOTE_VIEWS, remoteViews ) ; 


sendBroadcast(intent); 


A 的 代码 也 很 简单 ， 只 需要 接收 B 中 的 广播 并 显示 RemoteViews 即 
可 ， 如 下 所 示 。 


public class MainActivity extends Activity { 
private static final String TAG = "MainActivity"; 
private LinearLayout mRemoteViewsContent; 
private BroadcastReceiver mRemoteViewsReceiver=new Broad 
@Override 
public void onReceive(Context context,Intent intent) 
RemoteViews remoteViews = intent.getParcelableEx 
if (remoteViews != null) { 


updateUI(remoteViews) ; 


i 
@Override 


protected void onCreate(Bundle savedInstanceState) { 


super .onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_main); 
initView(); 

} 

private void initView() { 
mRemoteViewsContent = (LinearLayout) findViewById(R. 
IntentFilter filter = new IntentFilter(MyConstants.R 
registerReceiver (mRemoteViewsReceiver, filter); 

} 

private void updateUI(RemoteViews remoteViews) { 
View view = remoteViews.apply(this, mRemoteViewsConte 
mRemoteViewsContent .addView(view) ; 

} 

@Override 

protected void onDestroy() { 
unregisterReceiver (mRemoteViewsReceiver ); 


super.onDestroy(); 


上 述 代 码 很 简单 ， 除 了 注册 和 人 解除 广播 以 外 ， 最 主要 的 逻辑 其 实 就 
是 updateUI 方 法 。 当 A 收 到 广播 后 ， 会 从 Intent 中 取出 RemoteViews 对 
象 ， 然 后 通过 它 的 apply 方 法 加 载 布局 文件 并 执行 更 新 操作 ， 最 后 将 得 
到 的 View 添 加 到 A 的 布局 中 即 可 。 可 以 发 现 ， 这 个 过 程 很 简单 ， 但 是 通 
知 栏 的 底层 就 是 这 么 实现 的 。 








本 节 这 个 例子 是 可 以 在 实际 中 使 用 的 ， 比 如 现在 有 两 个 应 用 ， 一 个 


应 用 需要 能 够 更 新 另 一 个 应 用 中 的 某 个 界面 ， 这 个 时 候 我 们 当然 可 以 选 
择 AIDL 去 实现 ， 但 是 如 果 对 界面 的 更 新 比较 频繁 ， 这 个 时 候 就 会 有 效 
率 问 题 ， 同 时 AIDL 接 口 就 有 可 能 会 变 得 很 复杂 。 这 个 时 候 如 果 采 用 
RemoteViews 来 实现 就 没有 这 个 问题 了， 当然 RemoteViews 也 有 缺 点 ， 
那 束 是 它 仪 支持 一 些 常 见 的 View， 对 于 上 自 定义 View 它 是 不 文 持 的 。 面 
对 这 种 问题 ， 到 底 是 采用 AIDL 还 是 采用 RemoteViews， 这 个 要 看 具体 情 
况 ， 如 果 界 面 中 的 View 都 是 一 些 简 单 的 且 被 RemoteViews 文 持 的 View， 
那么 可 以 考虑 采用 RemoteViews， 人 否则 就 不 适合 用 RemoteViews 了 。 








如 果 打 算 采 用 RemoteViews 来 实现 两 个 应 用 之 间 的 界面 更 新 ， 那 么 
这 里 还 有 一 个 问题 ， 那 就 是 布局 文件 的 加 载 问题 。 在 上 面 的 代码 中 ， 我 
们 直接 通过 RemoteViews 的 apply 方 法 来 加 载 并 更 新 界面 ， 如 下 所 示 。 


View view = remoteViews.apply(this,mRemoteViewsContent); 


mRemoteViewsContent.addView(view); 


这 种 写法 在 同一 个 应 用 的 多 进程 情形 下 是 适用 的 ， 但 是 如 果 A 和 B 
属于 不 同 应 用 ， 那 么 B 中 的 布局 文件 的 资源 id 传输 到 A 中 以 后 很 有 可 能 是 
无 效 的 ， 因 为 A 中 的 这 个 布局 文件 的 资源 id 不 可 能 刚好 和 B 中 的 资源 id 一 
样 ， 面 对 这 种 情况 ， 我 们 就 要 适当 修改 RemoteViews 的 显示 过 程 的 代码 
了 。 这 里 给 出 一 种 方法 ， 既 然 资源 id 不 相同 ， 那 我 们 就 通过 资源 名 称 来 
加 载 布局 文件 。 首 先 两 个 应 用 要 提前 约定 好 RemoteViews 中 的 布局 文件 
的 资源 名 称 ， 比 如 “layout_simulated_notification”， 然 后 在 A 中 根据 名 称 
查找 到 对 应 的 布局 文件 并 加 载 ， 接 着 再 调用 RemoteViews 的 reapply 方 法 
即 可 将 B 中 对 View 所 做 的 一 系列 更 新 操作 全 部 作用 到 A 中 加 载 的 View 上 
。 关 于 apply 和 reapply 方 法 的 差别 在 前 面 已 经 提 到 过 ， 这 里 就 不 多 说 
了 ， 这 样 整个 跨 应 用 更 新 界面 的 流程 就 走 通 了 ， 具 体 效 果 如 图 5-4 所 
示 。 可 以 发 现 B 中 的 布局 文件 已 经 成 功 地 在 A 中 显示 了 出 来 。 修 改 后 的 
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代码 如 下 : 


int layoutId = getResources().getIdentifier("layout_simulated 
View view = getLayoutInflater().inflate(layoutId, mRemoteViews 
remoteViews.reapply(this, view); 


mRemoteViewsContent .addView( view) ; 
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通知 栏 消息 


发 送 模拟 通知 栏 消息 


msg from process:23056 


open DemoActivity_2 





图 5-4 模拟 通知 栏 的 效果 


第 6 Android 的 Drawable 


本 章 所 讲述 的 话题 是 Android 的 Drawable，Drawable 表 示 的 是 一 种 可 
以 在 Canvas 上 进行 绘制 的 抽象 的 概念 ， 它 的 种 类 有 很 多 ， 最 常见 的 颜色 
和 图 片 都 可 以 是 一 个 Drawable。 在 本 章 中 ， 首 先 描 述 Drawable 的 层次 关 
系 ， 接 着 介绍 Drawable 的 分 类 ， 最 后 介绍 自 定义 Drawable 相 关 的 知识 。 
本 章 的 内 容 看 起 来 稍微 有 点 简单 ， 但 是 由 于 Drawable 的 种 类 比较 党 多 ， 
从 而 导致 了 开发 者 对 不 同 Drawable 的 理解 比较 混乱 。 另 外 一 点 ， 熟 练 党 
握 各 种 类 型 的 Drawable 可 以 方便 我 们 做 出 一 些 特 殊 的 UI 效 果 ， 这 一 点 在 
UI 相关 的 开发 工作 中 尤其 重要 。Drawable 在 开发 中 有 着 自己 的 优点 : 首 
先 ， 它 使 用 简单 ， 比 自 定义 View 的 成 本 要 低 ;， 其 次 ， 非 图 片 类 型 的 
Drawable 占 用 空间 较 小 ， 这 对 减 小 apk 的 大 小 也 很 有 帮助 。 鉴 于 上 述 两 
点 ， 全 面 理解 Drawable 的 使 用 细节 还 是 很 有 必要 的 ， 这 也 是 本 章 的 出 发 
Fa 











6.1 Drawable 简 介 


Drawable 有 很 多 种 ， 它 们 都 表示 一 种 图 像 的 概念 ， 但 是 它们 又 不 全 
是 图 片 ， 通 过 颜色 也 可 以 构造 出 各 式 各 样 的 图 像 的 效果 。 在 实际 开发 
中 ，Drawable 常 被 用 来 作为 View 的 背景 使 用 。Drawable 一 般 都 是 通过 
XML 来 定义 的 ， 当 然 我 们 也 可 以 通过 代码 来 创建 具体 的 Drawable 对 象 ， 
只 是 用 代码 创建 会 稍 显 复杂 。 在 Android 的 设计 中 ，Drawable 是 一 个 抽 
象 类 ， 它 是 所 有 Drawable 对 象 的 基 类 ， 每 个 具体 的 Drawable 都 是 它 的 子 
类 ， 比 如 ShapeDrawable、BitmapDrawable 等 ，Drawable 的 层次 关系 如 图 
6-1 所 示 。 





4 © Object - java.lang 
a ^ Drawable - android.graphics.drawable 
AnimatedVectorDrawable - android.graphics.drawable 
BitmapDrawable - android.graphics.drawable 
ClipDrawable - android.graphics.drawab 
ColorDrawable - android.graphics.drawable 
DrawableContainer - android.graphics.drawable 
© AnimationDrawable - android.graphics.drawable 
© LevelListDrawable - android.graphics.drawable 
4 © StateListDrawable - android graphics.drawable 
© AnimatedStateListDrawable - android.graphics.drawable 

GradientDrawable - android.graphics.drawable 

InsetDrawable 

InsetDrawable d.gra 

Q SlideDrawable - android 

LayerDrawable - android.graphics.drawable 

© RippleDrawable - android.graphics.drawable 

© TransitionDrawable - android.graphics.drawable 

NinePatchDrawable - and 

PictureDrawable - android.c 

RotateDrawable - android.graphics.drawable 


© 
© 
© 
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ScaleDrawable - android.gra 

ShapeDrawable - android.graphics.drawable 
© PaintDrawable - android.graphics.drawable 
VectorDrawable - android 


© ©0000 





图 6-1 Drawable 的 层次 关系 


Drawable 的 内 部 宽 / 高 这 个 参数 比较 重要 ， 通 过 getIntrinsicWidth 和 
getIntrinsicHeight 这 两 个 方法 可 以 获取 到 它们 。 但 是 并 不 是 所 有 的 
Drawable 都 有 内 部 宽 / 高 ， 比 如 一 张 图 片 所 形成 的 Drawable， 它 的 内 部 
宽 / 高 就 是 图 片 的 宽 / 高 ， 但 是 一 个 颜色 所 形成 的 Drawable， 它 就 没有 内 
部 宽 / 高 的 概念 。 另 外 需要 注意 的 是 ，Drawable 的 内 部 宽 / 高 不 等 同 于 它 
的 大 小 ， 一 般 来 说 ，Drawable 是 没有 大 小 概念 的 ， 当 用 作 View 的 背景 
时 ，Drawable 会 被 拉 伸 至 View 的 同等 大 小 。 

















6.2 ”Drawable 的 分 类 


Drawablef) ##22 3 & , AY DLAY A BitmapDrawable, ShapeDrawable. 
LayerDrawable 以 及 StateListDrawable 等 ， 这 里 就 不 一 一 列举 了 ， 下 面 会 
分 别 介 绍 它们 的 使 用 细节 。 


6.2.1 BitmapDrawable 


这 几 平 是 最 简单 的 Drawable 了 ， 它 表示 的 就 是 一 张 图 片 。 在 实际 开 
发 中 ， 我 们 可 以 直接 引用 原始 的 图 片 即 可 ， 但 是 也 可 以 通过 XML 的 方 
式 来 描述 它 ， 通 过 XML 来 描述 的 BitmapDrawable 可 以 设置 更 多 的 效果 ， 
如 下 所 示 : 





<?xml version="1.0" encoding="utf-8"?> 
<bitmap 
xmins:android="http://schemas.android.com/apk/res/androi 


android: src="@[ package: ]drawable/drawable_resource" 


android:antialias=["true" | "false"] 
android:dither=["true" | "false" ] 

android: filter=["true" | "false" ] 

android:gravity=["top" | "bottom"|"left"|"right" | "cent 


"fill _ vertical"|"center_horizontal" | 
ecencete J ili J velipevertacak! | 
android:mipMap=["true" | "false" ] 


android: tileMode=["disabled" | "clamp" | "repeat" | "mir 


下 面 是 它 各 个 属性 的 含义 。 
android:src 

这 个 很 简单 ， 就 是 图 片 的 资源 id。 
android:antialias 


是 否 开 局 图 片 抗 锯齿 功能 。 开 局 后 会 让 图 片 变 得 平 消 ， 同 时 也 会 在 
一 定 程 度 上 降低 图 片 的 清晰 度 ， 但 是 这 个 降低 的 幅度 较 低 以 全 于 可 以 忽 
略 ， 因 此 抗 锯 此 选项 应 该 开局 。 


android:dither 


是 否 开 启 抖动 效果 。 当 图 片 的 像素 配置 和 手机 屏幕 的 像素 配置 不 一 
致 时 ， 开 启 这 个 选项 可 以 让 高 质量 的 图 片 在 低 质量 的 屏幕 上 还 能 保持 较 
好 的 显示 效果 ， 比 如 图 片 的 色彩 模式 为 ARGB8888， 但 是 设备 屏幕 所 文 
持 的 色彩 模式 为 RGB555， 这 个 时 候 开启 抖动 选项 可 以 让 图 片 显示 不 会 
过 于 失真 。 在 Android 中 创建 的 Bitmap 一 般 会 选用 ARGB8888 这 个 模式 ， 
即 ARGB 四 个 通道 各 占 8 位 ， 在 这 种 色彩 模式 下 ， 一 个 像素 所 占 的 大 小 
为 4 个 字 节 ， 一 个 像素 的 位 数 总 和 越 高 ， 图 像 也 就 越 逼 真 。 根 据 分 析 ， 
抖动 效果 也 应 该 开启 。 








android:filter 


古人 否 开局 过 小 效 打 。 当 图 片 太 寸 和 被 拉 伸 或 者 压缩 时 ， 开 局 过 滤 效 果 
可 以 保持 较 好 的 显示 效果 ， 因 此 此 选项 也 应 该 开局 。 


android:gravity 


当 图 片 小 于 容器 的 尺寸 时 ， 设 置 此 选项 可 以 对 图 片 进行 定位 。 这 个 
属性 的 可 选项 比较 多 ， 不 同 的 选项 可 以 通过 “|? 来 组 合 使 用 ， 如 表 6-1 所 


>` 
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表 6-1 gravity 属 性 的 可 选项 


图 片 放 在 容器 的 项 部， 不 改变 图 片 的 大 小 
到 片 放 在 容器 的 底部 ， 不 改变 图 片 的 大 小 
到 片 放 在 容器 的 左 部 ， 不 改变 图 片 的 大 小 
到 片 放 在 容器 的 右 部 ， 不 改变 图 片 的 大 小 
到 片 竖 直 居中 ， 不 改变 图 片 的 大 小 

1 坚 直 方向 填充 容器 
图 片 水 平 居 中 ， 不 改变 图 片 的 大 小 
1 水 平方 向 填充 容器 
习 片 在 水 平和 竖 直 方向 同时 居中 ， 不 改变 图 片 的 大 小 
1 在 水 平和 竖 直 方向 均 填充 容器 ， 这 是 默认 值 


clip_vertical 附加 选项 ， 表 示 竖 直方 向 的 裁剪 ， 较 少 使 用 
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clip_horizontal 附加 选项 ， 表 示 水 平方 向 的 裁剪 ， 较 少 使 用 








android:mipMap 


这 是 一 种 图 像 相 关 的 处 理 技术 ， 也 叫 纹理 映射 ， 比 较 抽 象 ， 这 里 也 
不 对 其 深 完 了 ， 默 认 值 为 false， 在 日 常 开发 中 此 选项 不 常用 。 





android:tileMode 


平 铺 模式 。 这 个 选项 有 如 下 几 个 值 : 
["disabled"|"clamp"|"repeat"|"mirror"]， 其 中 disable 表 示 关 闭 平 铺 模式 ， 这 
也 是 默认 值 ， 当 开局 平 铺 模式 后 ，gravity 属 性 会 被 忽略 。 这 里 主要 说 一 
下 repeat、mirror 和 clamp 的 区 别 ， 这 三 者 都 表示 平 铺 模式 ， 但 是 它们 的 
表现 却 有 很 大 不 同 。repeat 表 示 的 是 简单 的 水 平和 竖 直 方向 上 的 乎 铺 效 
果 ; mirror 表 示 一 种 在 水 平和 竖 直 方向 上 的 镜面 投影 效果 ;而 clamp 表 示 
的 效果 就 更 加 奇特 ， 图 片 四 周 的 像素 会 扩展 到 周围 区 域 。 下 面 我 们 看 一 
下 这 三 者 的 实际 效果 ， 通 过 实际 效果 可 以 更 好 地 理解 不 同 的 平 铺 模 式 的 








区 别 ， 如 图 6-2 所 示 。 
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(1) repeat (2) mirror (3) clamp 


图 6-2 平 铺 模式 下 的 图 片 显示 效果 


接 下 来 介绍 NinePatchDrawable， 它 表示 的 是 一 张 .9 格式 的 图 片 ，.9 
图 片 可 以 自动 地 根据 所 需 的 宽 / 蜗 进行 相应 的 缩放 并 保证 不 失真 ， 之 所 
以 把 它 和 BitmapDrawable 放 在 一 起 介绍 是 因为 它们 都 表示 一 张 图 片 。 和 
BitmapDrawable 一 样 ， 在 实际 使 用 中 直接 引用 图 厂 妈 可， 但 是 也 可 以 通 
过 XML 来 描述 .9 图 ， 如 下 所 示 。 





<?xml version="1.0" encoding="utf -8"?> 

<nine-patch 
xmlns:android="http://schemas.android.com/apk/res/androi 
android: src="@[package: ]drawable/drawable_resource" 


android:dither=["true" | "false"] /> 


上 述 XML 中 的 属性 的 含义 和 BitmapDrawable 中 的 对 应 属性 的 含义 是 
相同 的 ， 这 里 惑 不 再 描述 了 ， 另 外 ， 在 实际 使 用 中 发 现在 bitmap 标 签 中 
也 可 以 使 用 .9 图 ， 即 BitmapDrawable 也 可 以 代表 一 个 .9 格式 的 图 片 。 


6.2.2 ShapeDrawable 


ShapeDrawable 是 一 种 很 常见 的 Drawable， 可 以 理解 为 通过 颜色 来 
构造 的 网 形 ， 它 既 可 以 是 纯色 的 网 形 ， 也 可 以 是 具有 渐变 效果 的 图 形 。 
ShapeDrawable 的 语法 稍 显 复杂 ， 如 下 所 示 。 








<?xml version="1.0" encoding="utf-8"?> 
<shape 
xmins:android="http://schemas.android.com/apk/res/androi 
android:shape=["rectangle" | "oval" | "line" | "ring"] > 
<corners 
android: radius="integer" 
android: topLeftRadius="integer" 
android: topRightRadius="integer" 
android: bottomLeftRadius="integer" 
android: bottomRightRadius="integer" /> 
<gradient 
android: angle="integer" 
android: centerX="integer" 
android: centerY="integer" 
android: centerColor="integer" 
android: endColor="color" 
android: gradientRadius="integer" 


android:startColor="color" 


android: type=["linear" | "radial" | "Sweep" ] 
android:useLevel=["true" | "false"] /> 
<padding 


android: left="integer" 


android: top="integer" 


android: right="integer" 

android: bottom="integer" /> 
<size 

android: width="integer" 

android: height="integer" /> 
<solid 

android:color="color" /> 
<stroke 

android:width="integer" 

android:color="color" 

android: dashwidth="integer" 

android:dashGap="integer" /> 


</shape> 


需要 注意 的 是 <shape> 标 签 创 建 的 Drawable， 其 实体 类 实际 上 是 
GradientDrawable， 下 面 分 别 介绍 各 个 属性 的 含义 。 


android:shape 


表示 图 形 的 形状 ， 有 四 个 选项 : rectangle GE) . oval CHM 
ll) ~ line R) 和 ring《〈 圆 环 ) 。 写 的 默认 值 是 矩形 ， 另 外 line 和 
ring 这 两 个 选项 必须 要 通过 <stroke> 标 签 来 指定 线 的 宽度 和 颜色 等 信息 ， 
否则 将 无 法 达到 预期 的 显示 效果 。 





针对 ring 这 个 形状 ， 有 5 个 特殊 的 属性 : android:innerRadius、 


android:thickness、android:innerRadiusRatio、android:thicknessRatio 和 
android:useLevel， 它 们 的 含义 如 表 6-2 所 示 。 


表 6-2 ring 的 属性 值 


Value Desciption 
android:innerRadius 圆 环 的 内 半径 ， 和 android:innerRadiusRatio 同时 存在 时 ， 以 android:innerRadius 为 准 
android:thickness 圆 环 的 厚度 ， 即 外 半径 减 去 内 半径 的 大 小 ， 和 android:thicknessRatio 同时 存在 时 ， 以 
android:thickness 为 准 
android:innerRadiusRatio 内 半径 占 整 个 Drawable 宽度 的 比例 ， 默 认 值 为 9。 如 果 为 nb， 那么 内 半径 = 宽度 /n 














android:thicknessRatio 厚度 占 整 个 Drawable 宽度 的 比例 ， 默 认 值 为 3。 如 果 为 nb， 那么 厚度 = 宽度 /n 
android:useLevel - 般 都 应 该 使 用 false, 否则 有 可 能 无 法 到 达 预 期 的 显示 效果 , 除非 它 被 当 作 LevelListDrawable 
来 使 用 











<corners> 


表示 shape 的 四 个 角 的 角度 。 它 只 适用 于 算 形 shape， 这 里 的 角度 是 
指 圆 角 的 程度 ， 用 px 来 表示 ， 它 有 如 下 5 个 属性 





e android:radius 为 四 个 角 同 时 设 定 相同 的 角度 ， 优 先 级 较 低 ， 会 
被 其 他 四 个 属性 履 羡 :; 


e android:topLeftRadius 





设 定 最 上 角 的 角度 ; 
设 定 右上 角 的 角度 ; 
设 定 最 下 角 的 角度 ; 
设 定 右 下 角 的 角度 。 


e android:topRightRadius 





e android:bottomLeftRadius 





e android:bottomRightRadius 





<gradient> 


它 与 <solid> 标 签 是 互相 排斥 的 ， 其 中 solid 表 示 纯 色 填 充 ， 而 
gradient 则 表示 渐变 效果 ，gradient 有 如 下 几 个 属性 : 





。android:angle 一 一 渐变 的 角度 ， 默 认为 0， 其 值 必 须 为 45 的 倍数 ，0 
表示 从 左 到 右 ，90 表 示 从 下 到 上 ， 具 体 的 效果 需要 自行 体验 ， 总 之 
角度 会 影响 渐变 的 方 同 ; 

渐变 的 中 心 点 的 横 坐标 ; 

渐变 的 中 心 点 的 纵 坐 标 ， 渐 变 的 中 心 点 会 影响 





e android:centerX 





e android:center Y. 





渐变 的 具体 效果 ; 
e android:startColor 一 一 渐变 的 起 始 色 ，; 
e android:centerColor 一 一 渐变 的 中 间 色 ; 
e android:endColo 一 一 渐变 的 结束 色 ; 


渐变 半径 ， 仅 当 android:type= "radial" 时 








e android:gradientRadius 





有 效 ; 
eandroid:useLevel 一般 为 false， 当 Drawable 作 为 StateListDrawable 
使 用 时 为 true; 


。 android:type -一 渐变 的 类 别 ， 有 linear 〈 线 性 渐变 ) ~ radial 〈 径 向 
渐变 ) . sweep “扫描 线 渐 变 ) 三 种 ， 其 中 默认 值 为 线性 渐变 ， 它 
们 三 者 的 区 别 如 图 6-3 所 示 。 





图 6-3 渐变 的 类 别 ， 从 左 到 右 依次 为 1inear、radial、sweep 
<solid> 


这 个 标签 表示 纯色 填充 ， 通 过 android:color 即 可 指定 shape 中 填充 的 
aE. 


<stroke> 





Shape 的 描 边 ， 有 如 下 几 个 属性 : 


android:width 一 一 描 边 的 宽度 ， 越 大 则 shape 的 边缘 线 融会 看 起 来 越 
粗 ; 

android:color 一 描 边 的 颜色 ; 

android:dashWidth 一 一 组 成 虚线 的 线段 的 宽度 ; 

android:dashGap 一 一 组 成 虚线 的 线段 之 间 的 间隔 ， 间 隔 越 大 则 虚线 
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注意 如 果 android:dashWidth 和 android:dashGap 有 任何 一 个 为 0， 那 么 


虚线 效果 将 不 能 生效 。 下 面 是 一 个 具体 的 例子 ， 效 果 图 如 图 6-4 所 示 。 





图 6-4 ” shape 的 描 边 效果 


<?xml version="1.0" encoding="utf-8"?> 
<shape xmlns:android="http://schemas.android.com/apk/res/andr 
android: shape="rectangle" > 


<solid android:color="#ff0000" /> 


<stroke 
android: dashGap="2dp" 
android: dashwidth="10dp" 
android:width="2dp" 
android:color="#00ff00" /> 


</shape> 


<padding> 





这 个 表示 空白 ， 但 是 它 表 示 的 不 是 shape 的 空白 ， 而 是 包含 它 的 
View 的 空白 ， 有 四 个 属性 : android:left、android:top、android:right 和 和 


android:bottom. 
<size> 


shape 的 大 小 ， 有 两 个 属性 : android:width#landroid:height, 4) 5) 
示 shape 的 宽 / 高 。 这 个 表示 的 是 shape 的 固有 大 小 ， 但 是 一 般 来 说 它 并 不 
是 shape 最 终 显示 的 大 小 ， 这 个 有 点 抽象 ， 但 是 我 们 要 明白 ， 对 于 shape 
来 说 它 并 没有 宽 / 高 的 概念 ， 作 为 View 的 背景 它 会 自 适 应 View 的 宽 / 高 。 
我 们 知道 Drawable 的 两 个 方法 getIntrinsicWidth 和 getIntrinsicHeight 表 示 
的 是 Drawable 的 固有 和 宽 / 高 ， 对 于 有 些 Drawable 比 如 图 片 来 说 ， 它 的 固有 
a 而 对 于 shape 来 说 ， 默 认 情 况 下 它 是 没有 固有 宽 / 

这 个 概念 的 ， 这 个 时 候 getIntrinsicWidth 和 getIntrinsicHeight 会 返回 -1， 
See en 来 指定 宽 / 高 信息 ， 那 么 这 个 时 候 shape 就 有 了 
所 谓 的 固有 宽 / 高 。 因 此 ， 总 结 来 说 ，<size> 标 签 设置 的 宽 / 高 就 是 
ShapeDrawable 的 固有 宽 / 高 ， 但 是 作为 View 的 背景 时 ，shape 还 会 被 拉 伸 
或 者 缩小 为 View 的 大 小 。 












































6.2.3 LayerDrawable 


LayerDrawable 对 应 的 XML 标签 是 <layer-list>， 它 表示 一 种 层次 化 的 
Drawable 集 合 ， 通 过 将 不 同 的 Drawable 放 置 在 不 同 的 层 上 面 从 而 达到 一 
种 有 车 加 后 的 效果 。 它 的 语法 如 下 所 示 。 





<?xml version="1.0" encoding="utf-8"?> 


<layer-list 


xmins:android="http://schemas.android.com/apk/res/androi 


<item 


android: 
android: 
android: 
android: 
android: 


android: 


</layer-list> 


drawable="@[package: |drawable/drawable_resou 
id="@[+][package: ]id/resource_name" 
top="dimension" 

right="dimension" 

bottom="dimension" 


left="dimension" /> 


一 个 layer-list 中 可 以 包含 多 个 item， 每 个 item 表 示 一 个 Drawable。 
Item 的 结构 也 比较 简单 ， 比 较 常 用 的 属性 有 android:top、 
android:bottom、android:left 和 android:right， 它 们 分 别 表 示 Drawable 相 对 
于 View 的 上 下 左右 的 偏 移 量 ， 单 位 为 像素 。 男 外 ， 我 们 可 以 通过 





android:drawable 属 性 来 直接 引用 一 个 已 有 的 Drawable 资 源 ， 也 可 以 在 
item 中 自 定 义 Drawable。 默 认 情 况 下 ，layer-list 中 的 所 有 的 Drawable 都 会 


被 缩放 至 View 的 大 小 ， 


对 于 bitmap 来 说 ， 需 要 使 用 android:gravity 属 性 才 


能 控制 图 片 的 显示 效果 。Layer-list 有 层次 的 概念 ， 下 面 的 item 会 覆盖 上 
面 的 item， 通 过 合理 的 分 层 ， 可 以 实现 一 些 特殊 的 登 加 效果 。 


下 面 是 一 个 layer-list 具 体 使 用 的 例子 ， 它 实现 了 微 信 中 的 文本 输入 
框 的 效果 ， 如 图 6-5 所 示 。 当 然 它 只 适用 于 白色 背景 上 的 文本 输入 框 ， 
另外 这 种 效果 也 可 以 采用 .9 图 来 实现 。 


文本 框 





图 6-5 layer-list 的 应 用 





</layer-list> 


6.2.4 StateListDrawable 


StateListDrawable 对 应 于 <selector> 标 签 ， 它 也 是 表示 Drawable 集 
合 ， 每 个 Drawable 都 对 应 着 View 的 一 种 状态 ， 这 样 系统 就 会 根据 View 
的 状态 来 选择 合适 的 Drawable。 StateListDrawable 主 要 用 于 设置 可 单 击 
的 View 的 背景 ， 最 常见 的 是 Button， 这 个 读者 应 该 不 陌生 ， 它 的 语法 如 
下 所 示 。 





<?xml version="1.0" encoding="utf-8"?> 


<selector xmlns:android="http://schemas.android.com/apk/res/a 


android:constantSize=["true" | "false" 
android:dither=["true" | "false" ] 

android: variablePadding=["true" | "false"] > 
<item 


android: drawable="@[ package: ]drawable/drawable_resou 


android:state_pressed=["true" | "false"] 
android:state_focused=["true" | "false"] 
android:state_hovered=["true" | "false"] 
android:state_selected=["true" | "false" ] 
android:state_checkable=["true" | "false" ] 
android:state_checked=["true" | "false" ] 
android:state_enabled=["true" | "false"] 
android:state_activated=["true" | "false" ] 


android:state_window_focused=["true" | "false"] /> 


</selector> 


针对 上 面 的 语法 ， 下 面 做 简单 介绍 。 


android:constantSize 





StateListDrawable 的 固有 大 小 是 否 不 随 着 其 状态 的 改变 而 改变 的 ， 
为 状态 的 改变 会 导致 StateListDrawable 切 换 到 具体 的 Drawable， 而 不 
同 的 Drawable 具 有 不 同 的 固有 大 小 。True 表 示 StateListDrawable 的 固有 
大 小 保持 不 变 ， 这 时 它 的 固有 大 小 是 内 部 所 有 Drawable 的 固有 大 小 的 最 
大 值 ，false 则 会 随 着 状态 的 改变 而 改变 。 此 选项 默认 值 为 false。 





android: dither 


是 否 开启 抖动 效果 ， 这 个 在 BitmapDrawable 中 也 有 提 到 ， 开 启 此 选 
项 可 以 让 图 斤 在 低 质 量 的 屏幕 上 仍然 获得 较 好 的 显示 效果 。 此 选项 默认 
值 为 true。 





android:variablePadding 





StateListDrawable 的 padding 表 示 是 否 随 痢 其 状态 的 改变 而 改变 ， 
true 表 示 会 随 着 状态 的 改变 而 改变 ，false 表 示 StateListDrawable 的 padding 
是 内 部 所 有 Drawable 的 padding 的 最 大 值 。 此 选项 默认 值 为 false， 并 且 不 
建议 开启 此 选项 。 





<item> 标 签 表示 一 个 具体 的 Drawable， 它 的 结构 也 比较 简单 ， 其 中 
android:drawable 是 一 个 已 有 Drawable 的 资源 id， 剩 下 的 属性 表示 的 是 
View 的 各 种 状态 ， 每 个 item 表 示 的 都 是 一 种 状态 下 的 Drawable 信 息 。 
View 的 常见 状态 如 表 6-3 所 示 。 








表 6-3 View # LRA 


K A a x 





android:state_pressed 表示 按 下 状态 ， 比 如 Button 被 按 下 后 仍 没有 松 开 时 的 状态 





android:state focused 





android:state_selected 表示 用 户 选择 了 View 
android:state_checked 表示 用 户 选中 了 View， 一 般 适 用 于 CheckBox 这 类 在 选中 和 非 选中 状态 之 间 进 行 切换 的 View 














android:state_enabled 表示 View 当前 处 于 可 用 状态 


下 面 给 出 具体 的 例子 ， 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 
<selector xmlns:android="http://schemas.android.com/apk/res/a 

<item android:state_pressed="true" 
android: drawable="@drawable/button_pressed" /> <!- 

<item android:state_focused="true" 
android: drawable="@drawable/button_focused" /> <!- 
<item android: drawable="@drawable/button_normal" /> <!-- 


</selector> 


系统 会 根据 View 当 前 的 状态 从 selector 中 选择 对 应 的 item， 每 个 item 
对 应 着 一 个 具体 的 Drawable， 系 统 按 照 从 上 到 下 的 顺序 查找 ， 直 人 到 查找 
到 第 一 条 匹配 的 item。 一 般 来 说 ， 默 认 的 item 都 应 该 放 在 selector 的 最 后 
一 条 并 且 不 附带 任何 的 状态 ， 这 样 当 上 面 的 item 都 无 法 匹配 View 的 当前 
状态 时 ， 系 统 就 会 选择 默认 的 item， 因 为 默认 的 item 不 附带 状态 ， 所 以 
它 可 以 匹配 View 的 任何 状态 。 


6.2.5 LevelListDrawable 


LevelListDrawable 对 应 于 <level-list> 标 签 ， 它 同样 表示 一 个 


Drawable 人 集合， 集合 中 的 每 个 Drawable 都 有 一 个 等 级 devel) 的 概念 。 
根据 不 同 的 等 级 ，LevelListDrawable 会 切换 为 对 应 的 Drawable， 它 的 语 
法 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 
<level-list 
xmins:android="http://schemas.android.com/apk/res/androi 
<item 
android: drawable="@drawable/drawable_resource" 
android:maxLevel="integer" 
android:minLevel="integer" /> 


</level-list> 


上 面 的 语法 中 ， 每 个 item 表 示 一 个 Drawable， 并 且 有 对 应 的 等 级 范 
， 由 android:min-Level 和 android:maxLevel 来 指定 ， 在 最 小 值 和 最 大 值 
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作为 View 的 背景 时 ， 可 以 通过 Drawable 的 setLeve] 方 法 来 设置 不 同 的 等 
级 从 而 切换 具体 站 Drawable。 如 果 它 被 用 来 作为 InageView 的 前 景 
Drawable， 那 么 还 可 以 通过 ImageView 的 setImageLevel 方 法 来 切换 
Drawable。 最 后 ，Drawable 的 等 级 是 有 范围 的 ， 即 0 一 10000， 最 小 等 级 
是 0， 这 也 是 默认 值 ， 最 大 等 级 是 10000。 














<?xml version="1.0" encoding="utf-8"?> 
<level-list xmlns:android="http://schemas.android.com/apk/res 
<item 
android: drawable="@drawable/status_off" 
android:maxLevel="0" /> 


<item 


android: drawable="@drawable/status_on" 
android:maxLevel="1" /> 


</level-list> 


6.2.6 TransitionDrawable 


TransitionDrawable 对 应 于 <transition> 标 签 ， 它 用 于 实现 两 个 
Drawable 之 间 的 淡 入 淡出 效果 ， 它 的 语法 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 
<transition 
xmins:android="http://schemas.android.com/apk/res/android" > 
<item 
android: drawable="@[ package: ]drawable/drawable_resou 
android: id="@[+][package: ]id/resource_name" 
android: top="dimension" 
android: right="dimension" 
android: bottom="dimension" 
android: left="dimension" /> 


</transition> 


上 面 语法 中 的 属性 前 面 已 经 都 介绍 过 了 ， 其 中 android:top、 
android:bottom、android:left 和 android:right 仍 然 表 示 的 是 Drawable 四 周 的 
偏 移 量 ， 这 里 就 不 多 介绍 了 。 下 面 给 出 一 个 实际 的 例子 。 





首先 定义 TransitionDrawable， 如 下 所 示 。 


// vres/drawable/transition_drawable. xml 

<?xml version="1.0" encoding="utf-8"?> 

<transition xmlns:android="http://schemas.android.com/apk/res 
<item android: drawable="@drawable/drawablei" /> 
<item android: drawable="@drawable/drawable2" /> 


</transition> 


接着 将 上 面 的 TransitionDrawable 设 置 为 View 的 背景 ， 如 下 所 示 。 当 
然 也 可 以 在 ImageView 中 直接 作为 Drawable 来 使 用 。 


<TextView 
android: id="@t+id/button" 
android: Layout_height="wrap_content" 
android: Layout_width="wrap_content" 


android: background="@drawable/transition_drawable" /> 


最 后 ， 通 过 它 的 startTransition 和 reverseTransition 方 法 来 实现 淡 入 淡 
出 的 效果 以 及 它 的 逆 过 程 ， 如 下 所 示 。 





TextView textView = (TextView) findViewById(R.id.test_transit 
TransitionDrawable drawable = (TransitionDrawable) textView.g 


drawable.startTransition(1000) ; 


6.2.7 InsetDrawable 


InsetDrawable 对 应 于 <inset> 标 签 ， 它 可 以 将 其 他 Drawable 内 般 到 目 
己 当 中 ， 并 可 以 在 四 周 留 出 一 定 的 间距 。 当 一 个 View 和 希望 自己 的 背景 比 








上 自己 的 实际 区 域 小 的 时 候 ， 可 以 采用 InsetDrawable 来 实现 ， 同 时 我 们 知 
道 ， 通 过 LayerDrawable 也 可 以 实现 这 种 效果 。InsetDrawable 的 语法 如 下 
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<?xml version="1.0" encoding="utf-8"?> 

<inset 
xmins:android="http://schemas.android.com/apk/res/androi 
android: drawable="@drawable/drawable_resource" 
android: insetTop="dimension" 
android: insetRight="dimension" 
android: insetBottom="dimension" 


android: insetLeft="dimension" /> 


上 面 的 属性 都 比较 好 理解 ， 其 中 android:insetTop、 
android:insetBottom、android:insetLeft 和 android:insetRight 分 别 表示 项 
部 、 底 部 、 左 边 和 右边 内 止 的 大 小 。 在 下 面 的 例子 中 ，inset 中 的 shape 距 
离 View 的 边界 为 15dp。 





<?xml version="1.0" encoding="utf-8"?> 
<inset xmlns:android="http://schemas.android.com/apk/res/andr 
android: insetBottom="15dp" 
android: insetLeft="15dp" 
android: insetRight="15dp" 
android: insetTop="15dp" > 
<shape android:shape="rectangle" > 
<solid android:color="#ff0000" /> 
</shape> 


</inset> 


6.2.8 ScaleDrawable 





ScaleDrawable 对 应 于 <scale> 标 签 ， 它 可 以 根据 自己 的 等 级 (level) 
将 指定 的 Drawable 缩 放 到 一 定 比 例 ， 它 的 语法 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 

<scale 
xmins:android="http://schemas.android.com/apk/res/androi 
android: drawable="@drawable/drawable_resource" 
android:scaleGravity=["top" | "bottom" | "left" | "right 
vertical" |"fill_vertical" | "center_horizontal" | "fill 
android: scaleHeight="percentage" 


android: scalewWidth="percentage" /> 


在 上 面 的 属性 中 ，android:scaleGravity 的 含义 等 同 于 shape 中 的 
android:gravity， 而 android:scaleWidth 和 android:scaleHeight 分 别 表示 对 指 
定 Drawable 宽 和 高 的 缩放 比例 ， 以 百分比 的 形式 表示 ， 比 如 25%。 


ScaleDrawable 有 点 费解 ， 要 理解 它 ， 我 们 首先 要 明白 等 级 对 
ScaleDrawable 的 影响 。 等 级 0 表示 ScaleDrawable 不 可 见 ， 这 是 默认 值 ， 
要 想 ScaleDrawable 可 见 ， 需 要 等 级 不 能 为 0， 这 一 点 从 源码 中 可 以 得 
出 。 来 看 一 下 ScaleDrawable 的 draw 方 法 ， 如 下 所 示 。 





public void draw(Canvas canvas) { 
if (mScaleState.mDrawable.getLevel() != 0) 


mScaleState.mDrawable.draw(canvas); 





很 显然 ， 由 于 ScaleDrawable 的 等 级 和 mDrawable 的 等 级 是 保持 一 致 
的 ， 所 以 如 果 ScaleDrawable 的 等 级 为 0， 那 么 它 内 部 的 mDrawable 的 等 
级 也 必然 为 0， 这 时 mDrawable 束 无 法 绘制 出 来 ， 也 就 是 ScaleDrawable 
不 可 见 。 下 面 再 看 一 下 ScaleDrawable 的 onBoundsChange 方 法 ， 如 下 所 
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protected void onBoundsChange(Rect bounds) { 
final Rect r = mTmpRect; 
final boolean min = mScaleState.mUseIntrinsicSizeAsMin; 
int level = getLevel(); 
int w = bounds.width(); 
if (mScaleState.mScaleWidth > 0) { 
final int iw = min ? mScaleState.mDrawable.getInt 
w -= (int) ((w -iw) * (10000 -level) * mScaleStat 
j 
int h = bounds.height(); 
if (mScaleState.mScaleHeight > 0) { 
final int ih = min ? mScaleState.mDrawable.getInt 
h -= (int) ((h -ih) * (10000 -level) * mScaleStat 
J; 
final int layoutDirection = getLayoutDirection(); 
Gravity .apply(mScaleState.mGravity,w,h,bounds,r,layoutDir 
if (w> © && h > 0) { 


mScaleState.mDrawable.setBounds(r.left,r.top,r.ri 


在 ScaleDrawable 的 onBoundsChange 方 法 中 ， 我 们 可 以 看 出 
mDrawable 的 大 小 和 等 级 以 及 缩放 比例 的 关系 ， 这 里 拿 宽度 来 说 ， 如 下 


所 示 。 


final int iw = min ? mScaleState.mDrawable.getIntrinsicwidth( 


w -= (int) ((w -iw) * (10000 -level) * mScaleState.mScaleWidt 


由 于 iw 一 般 都 为 0， 所 以 上 面 的 代码 可 以 简化 为 : w -= (int) (w * 
(10000 -level) * mScaleState.mScaleWidth / 10000)。 由 此 可 见 ， 如 果 
ScaleDrawable 的 级 别 为 最 大 值 10000， 那 么 就 没有 缩放 的 效果 ; 如 果 
ScaleDrawable 的 级 别 〈level) 越 大 ， 那 么 内 部 的 Drawable 看 起 来 就 越 
大 ; 如 果 ScaleDrawable 的 XML 中 所 定义 的 缩放 比例 越 大 ， 那 么 内 部 的 
Drawable 看 起 来 就 越 小 。 另 外 ， 从 ScaleDrawable 的 内 部 实现 来 看 ， 
ScaleDrawable 的 作用 更 偏 铝 于 缩小 一 个 特定 的 Drawable。 在 下 面 的 例子 
中 ， 可 以 近似 地 将 一 张 图 片 缩小 为 原 大 小 的 30%， 代 码 如 下 所 示 。 


// res/drawable/scale drawable.xml 


<?xml version="1.0" encoding="utf-8"?> 


<scale xmlins: 
android: 
android: 
android: 


android: 


android="http://schemas.android.com/apk/res/andr 
drawable="@drawable/imagei" 

scaleHeight="70%" 

scaleWidth="70%" 


scaleGravity="center" /> 


直接 使 用 上 面 的 drawable 资 源 是 不 行 的 ， 还 必须 设置 ScaleDrawable 








的 等 级 为 大 于 0 且 小 于 等 于 10000 的 值 ， 如 下 所 示 。 


View testScale = findViewById(R.id.test_scale); 


ScaleDrawable testScaleDrawable = (ScaleDrawable) testScale.g 


testScaleDrawable.setLevel(1); 





经 过 上 面 的 两 步 可 以 正确 地 缩放 一 个 Drawable， 如 果 少 了 设置 等 级 
这 一 步 ， 由 于 Drawable 的 默认 等 级 为 0， 那 么 ScaleDrawable 将 无 法 显示 
出 来 。 我 们 本 CATRIN Hiv Drawable FR BEAK T1000089 比如 
20000， 虽 然 也 能 正常 工作 ， 但 是 不 推荐 这 么 做 ， 这 是 因为 系统 内 部 约 
定 Drawable 等 级 的 范围 为 0 到 10000。 


6.2.9 ClipDrawable 





ClipDrawable 对 应 于 <clip> 标 签 ， 它 可 以 根据 自己 当前 的 等 级 
(level) 来 裁剪 另 一 个 Drawable， 裁 剪 方向 可 以 通过 
android:clipOrientation 和 android:gravity 这 两 个 属性 来 共同 控制 ， 它 的 语 
法 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 
<clip 
xmins:android="http://schemas.android.com/apk/res/androi 
android: drawable="@drawable/drawable_resource" 
android:clipOrientation=["horizontal" | "vertical" ] 
android:gravity=["top" | "bottom"|"left" | "right"|"cent 
"fill vertical" |"center_horizontal"|"fi 


veencer. J tbl weii vertical’ | al 





其 中 clipOrientation 表 示 裁 前 方向 ， 有 水 平和 竖 直 两 个 方向 ，gravity 
比较 复杂 ， 需 要 和 dlipOrientation 一 起 才能 发 挥 作用 ， 如 表 6-4 所 示 。 男 


Sheravity h A Miz i AE AY WI | RA EA AY 
6-4 ClipDrawable 的 gravity 属 性 


a xX 

将 内 部 的 Drawable 放 在 容器 的 顶部 ， 不 改变 它 的 大 小 。 如 果 为 竖 直 裁剪 ， 那 么 从 底部 开始 裁剪 
bottom 将 内 部 的 Drawable 放 在 容器 的 底部 ， 不 改变 它 的 大 小 。 如 果 为 竖 直 裁剪 ， 那 么 从 顶部 开始 裁剪 

将 内 部 的 Drawable 放 在 容器 的 左边 ， 不 改变 它 的 大 小 。 如 果 为 水 平 裁剪 ， 那 么 从 右边 开始 裁剪， 这 
是 默认 值 
right 将 内 部 的 Drawable 放 在 容器 的 右边 ， 不 改变 它 的 大 小 。 如 果 为 水 平 裁剪 ， 那 么 从 左边 开始 裁剪 
center_vertical 使 内 部 的 Drawable 在 容器 中 坚 直 居中 ， 不 改变 它 的 大 小 。 如果 为 竖 直 裁剪 ， 那 么 从 上 下 同时 开始 裁剪 

使 内 部 的 Drawable 在 竖 直 方向 上 填充 容器 。 如 果 为 竖 直 裁剪 ， 那 么 仅 当 ClipDrawable 的 等 级 为 0 (0 
表示 ClipDrawable 被 完全 裁剪 ， 即 不 可 见 ) 时 ， 才 能 有 裁剪 行为 

使 内 部 的 Drawable 在 容器 中 水 平 居中 ， 不 改变 它 的 大 小 。 如 果 为 水 平 裁剪 ， 那 么 从 左右 两 边 同 时 开 
始 裁剪 

使 内 部 的 Drawable 在 水 平方 向 上 填充 容器 。 如 果 为 水 平 裁 彰 ， 那 么 仅 当 ClipDrawable 的 等 级 为 0 时 ， 
才能 有 裁剪 行为 

使 内 部 的 Drawable 在 容器 中 水 平和 竖 直 方向 都 居中 ， 不 改变 它 的 大 小 。 如 果 为 竖 直 裁剪 ， 那 么 从 上 
下 同时 开始 裁剪 ， 如 果 为 水 平 裁剪 ， 那 么 从 左右 同时 开始 裁剪 

使 内 部 的 Drawable 在 水 平和 竖 直方 向 上 同时 填充 容器 。 仅 当 ClipDrawable 的 等 级 为 0 时 ， 才 能 有 裁 
前 行为 
clip_vertical | ME, AeA META TT BT Beeb ARH 
clip_horizontal 附加 选项 ， 表 示 水 平方 向 的 裁剪 ， 较 少 使 用 
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先 定义 ClipDrawable，xml 如 下 : 


<?xml version="1.0" encoding="utf-8"?> 

<clip xmlns:android="http://schemas.android.com/apk/res/andro 
android:clipOrientation="vertical" 
android: drawable="@drawable/image1" 


android: gravity="bottom" /> 


在 上 面 的 XML 中 ， 因 为 我 们 要 实现 顶部 的 裁剪 效果 ， 所 以 裁剪 方 
向 应 该 为 竖 直 方向 ， 同 时 从 表 6-4 可 以 知道 ，gravity 属 性 应 该 选择 
bottom。 有 了 ClipDrawable 如 何 使 用 呢 ? 也 是 很 简单 的 ， 首 先 将 它 设置 
给 ImageView， 当 然 也 可 以 作为 普通 View 的 背景 ， 如 下 所 示 。 





<ImageView 
android: id="@t+tid/test_clip" 
android: Llayout_width="100dp" 
android: Layout_height="100dp" 
android: src="@drawable/clip_drawable" 


android: gravity="center" /> 


接着 在 代码 中 设置 ClipDrawable 的 等 级 ， 如 下 所 示 。 


ImageView testClip = (ImageView) findViewById(R.id.test_clip) 
ClipDrawable testClipDrawable = (ClipDrawable) testClip.getDr 
testClipDrawable.setLevel(5000); 


在 6.2.5 节 中 已 经 提 到 ，Drawable 的 等 级 〈level) 是 有 范围 的 ， 即 0 
一 10000， 最 小 等 级 是 9， 最 大 等 级 是 10000， 对 于 ClipDrawable 来 说 ， 等 
级 0 表示 完全 裁剪 ， 即 整个 Drawable 都 不 可 见 了 ， 而 等 级 10000 表 示 不 裁 
剪 。 在 上 面 的 代码 中 将 等 级 设置 为 8000 表 示 裁 前 了 2000， 即 在 顶部 裁剪 
折 20% 的 区 域 ， 被 裁剪 的 区 域 就 相当 于 不 存在 了 ， 有 具体 效果 如 几 6-6 所 
ZN o 








图 6-6 ClipDrawable 的 裁剪 效果 


对 于 本 例 来 说 ， 等 级 越 大 ， 表 示 裁 王 的 区 域 越 小 ， 因 此 等 级 10000 
表示 不 裁 蚤 ， 这 个 时 候 整 个 图 片 都 可 以 完全 显示 出 来 ， 而 等 级 0 则 表示 
裁 甬 全 部 区 域 ， 这 个 时 候 整 个 图 片 将 不 可 见 。 万 外 裁 甬 效果 还 受 裁 剪 方 
加 和 gravity 属 性 的 影响 ， 表 6-4 中 的 选项 读者 可 以 目 行 答 试 一 下 ， 这 样 就 
能 比较 好 地 理解 不 同属 性 对 裁 前 效果 的 影响 了 。 





6.3 Hic <Drawable 





Drawable 的 使 用 范围 很 单一 ， 一 个 是 作为 ImageView 中 的 图 像 来 显 
示 ， 男 外 一 个 就 是 作为 View 的 背景 ， 大 多 数 情 况 下 Drawable 都 是 以 
View 的 背景 这 种 形式 出 现 的 。Drawable 的 工作 原理 很 简单 ， 其 核心 就 是 
draw 方 法 。 在 第 5 章 中 ， 我 们 分 析 了 View 的 工作 原理 ， 我 们 知道 系统 会 
调用 Drawable 的 draw 方 法 来 绘制 View 的 背景 ， 从 这 一 点 我 们 明白 ， 可 以 
通过 重 写 Drawable 的 draw 方 法 来 自 定 义 Drawable。 


通常 我 们 没有 必要 去 自 定义 Drawable， 这 是 因为 自 定 义 的 Drawable 
无 法 在 XML 中 使 用 ， 这 就 降低 了 上 自 定义 Drawable 的 使 用 范围 。 某 些 特殊 
情况 下 我 们 的 确 想 自 定 义 Drawable， 这 也 是 可 以 的 。 下 面 演 示 一 个 自 定 
义 Drawable 的 实现 过 程 ， 我 们 通过 上 自 定 义 Drawable 来 绘制 一 个 圆 形 的 
Drawable， 并 且 它 的 半径 会 随 着 View 的 变化 而 变化 ， 这 种 Drawable 可 以 
作为 View 的 通用 背景 ， 代 码 如 下 所 示 。 


public class CustomDrawable extends Drawable { 

private Paint mPaint; 

public CustomDrawable(int color) { 
mPaint = new Paint(Paint.ANTI_ALIAS FLAG); 
mPaint.setColor(color); 

j 

@Override 

public void draw(Canvas canvas) { 
final Rect r = getBounds(); 


float cx = r.exactCenterX(); 


float cy = r.exactCenteryY(); 
canvas.drawCircle(cx,cy,Math.min(cx,cy),mPaint); 

$ 

@Override 

public void setAlpha(int alpha) { 
mPaint.setAlpha(alpha) ; 
invalidateSelf(); 

t 

@Override 

public void setColorFilter(ColorFilter cf) { 
mPaint.setColorFilter(cf); 
invalidateSelf(); 

} 

@Override 

public int getOpacity() { 
// not sure,so be safe 


return PixelFormat.TRANSLUCENT; 


在 上 面 的 代码 中 ，draw、setAlpha、setColorFilter 和 getOpacity 这 几 
个 方法 都 是 必须 要 实现 的 ， 其 中 draw 是 最 主要 的 方法 ， 这 个 方法 就 和 
View 的 draw 方 法 类 似 ， 而 setAlpha、setColorFilter 和 getOpacity 这 三 个 方 
法 的 实现 都 比较 简单 ， 这 里 不 再 多 说 了。 在 上 面 的 例子 中 ， 参 考 了 
ShapeDrawable 和 BitmapDrawable 的 源码 ， 所 以 说 ， 源 码 是 一 个 很 好 的 学 
习 资 料 ， 有 些 技 术 细 节 我 们 不 清楚 ， 就 可 以 查看 源码 中 类 似 功能 的 实现 
以 及 相应 的 文档 ， 这 样 就 可 以 更 有 针对 性 地 解决 一 些 问题 。 








上 上面 的 例子 比较 简单 ， 但 是 流程 是 完整 的 ， 读 者 可 以 根据 自己 的 需 
要 实现 更 复杂 的 目 定 义 Drawable。 另 外 getIntrinsicWidth 和 
getIntrinsicHeight 这 两 个 方法 需要 注意 一 下 ， 当 自 定 义 的 Drawable 有 固有 
大 小 时 最 好 重 写 这 两 个 方法 ， 因 为 它 会 影响 到 View 的 wrap_content 布 
局 ， 比 如 自 定 义 Drawable 是 绘制 一 张 图 乒 ， 那 么 这 个 Drawable 的 内 部 大 
小 就 可 以 选用 图 片 的 大 小 。 在 上 面 的 例子 中 ， 自 定义 的 Drawable 是 由 颜 
色 填 充 的 圆 形 并 且 没 有 固定 的 大 小 ， 因 此 没有 重 写 这 两 个 方法 ， 这 个 时 
候 它 的 内 部 大 小 为 -1， 即 内 部 宽度 和 内 部 高 度 都 为 -1。 需 要 注意 的 是 ， 
内 部 大 小 不 等 于 Drawable 的 实际 区 域 大 小 ，Drawable 的 实际 区 域 大 小 可 
以 通过 它 的 getBounds 方 法 来 得 到 ， 一 般 来 说 它 和 View 的 尺寸 相同 。 
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Android 的 动画 可 以 分 为 三 种 : View 动 画 、 帧 动画 和 属性 动画 ， 其 
实 帧 动画 也 属于 View 动 画 的 一 种 ， 只 不 过 它 和 平移、 旋转 等 常见 的 
View 动 男 在 表现 形式 上 略 有 不 同 而 已 。View 动 男 通 过 对 场景 里 的 对 象 
不 断 做 图 像 变 换 《〈 和 平移、 缩放 、 旋 转 、 透 明度 ) 从 而 产生 动画 效果 ， 它 
是 一 种 渐 近 式 动 画 ， 并 且 View 动 画 文 持 自 定 义 。 帧 动画 通过 顺序 播放 一 
系列 图 像 从 而 产生 动画 效果 ， 可 以 简单 理解 为 图 片 切换 动画 ， 很 显然 ， 
如 果 图 片 过 多 过 大 就 会 导致 OOM。 属 性 动画 通过 动态 地 改变 对 象 的 属 
性 从 而 达到 动画 效果 ， 属 性 动画 为 API 11 的 新 特性 ， 在 低 版 本 无 法 直接 
使 用 属性 动画 ， 但 是 我 们 仍然 可 以 通过 兼容 库 来 使 用 它 。 在 本 章 中 ， 首 
先 简单 介绍 View 动 画 以 及 自 定义 View 动 画 的 方式 ， 接 着 介绍 View 动 画 
的 一 些 特殊 的 使 用 场景 ， 最 后 对 属性 动画 做 一 个 全 面 性 的 介绍 ， 男 外 还 
介绍 使 用 动画 的 一 些 注意 事项 。 
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View 动 画 的 作用 对 象 是 View， 它 文 持 4 种 动画 效果 ， 分 别 是 平移 动 
画 、 缩 放 动 画 、 旋 转动 画 和 透明 上 度 动 画 。 除 了 这 四 种 典型 的 变换 效果 
外 ， 帧 动画 也 属于 View 动 画 ， 但 是 帧 动画 的 表现 形式 和 上 面 的 四 种 变换 
效果 不 太一 样 。 为 了 更 好 地 区 分 这 四 种 变换 和 帧 动画 ， 在 本 章 中 如 果 没 
有 特殊 说 明 ， 那 么 所 提 到 的 View 动 画 均 指 这 四 种 变换 ， 帧 动画 会 单独 介 
绍 。 本 节 将 介绍 View 动 画 的 四 种 效果 以 及 帧 动画 ， 同 时 还 会 介绍 上 自 定 义 
View 动 画 的 方法 。 


7.1.1 View 动 画 的 种 类 


View 动 画 的 四 种 变换 效果 对 应 着 Animation 的 四 个 子 类 : 
TranslateAnimation、ScaleAnimation、RotateAnimation 和 
AlphaAnimation， 如 表 7-1 所 示 。 这 四 种 动画 既 可 以 通过 XML 来 定义 ， 
也 可 以 通过 代码 来 动态 创建 ， 对 于 View 动 画 来 说 ， 建 议 采 用 XML 来 定 
义 动画 ， 这 是 因为 XML 格式 的 动画 可 读 性 更 好 。 


表 7-1 View 动画 的 四 种 变换 


名 称 F % 类 效 果 
平移 动画 ran 移动 View 
缩放 动画 <scale> 放大 或 缩小 View 











旋转 动画 <rotate> 旋转 View 








透明 度 动画 <alpha> 改变 View 的 透明 度 


要 使 用 View 动 画 ， 首 先 要 创建 动 男 的 XML 文件 ， 这 个 文件 的 路 径 
为 : res/aninmyfilename.xml。View 动 男 的 描述 文件 是 有 固定 的 语法 的 ， 如 








</set> 


</set> 


从 上 面 的 语法 可 以 看 出 ，View 动 画 既 可 以 古 单个 动画 ， 也 可 以 由 一 
系列 动画 组 成 。 





<set> 标 签 表示 动画 集合 ， 对 应 AnimationSet 类 ， 它 可 以 包含 略 干 个 
动画 ， 并 且 它 的 内 部 也 是 可 以 组 套 其 他 动画 集合 的 ， 它 的 两 个 属性 的 含 
义 如 下 : 


android:interpolator 


表示 动画 集合 所 采用 的 插值 器 ， 插 值 器 影响 动画 的 速度 ， 比 如 非 义 
速 动 画 束 需要 通过 插值 器 来 控制 动画 的 播放 过 程 。 这 个 属性 可 以 不 指 
定 ， 默 认为 @android:anim/accelerate_decelerate_interpolator， 即 加 速 减 
速 插值 器 ， 关 于 插值 器 的 概念 会 在 7.3.2 节 中 进行 具体 介绍 。 





android:shareInterpolator 


表示 集合 中 的 动画 是 否 和 集合 共 孚 同一 个 插值 器 。 如 果 集 合 不 指定 
插值 右 ， 那 么 子 动画 就 需要 单独 指定 所 需 的 插值 磊 或 者 使 用 默认 值 。 








<translate> 标 签 标 示 平 移动 画 ， 对 应 TranslateAnimation 关 ， 它 可 以 
使 一 个 View 在 水 平和 竖 直 方向 完成 平移 的 动画 效果 ， 它 的 一 系列 属性 的 
含义 如 下 : 





表示 x 的 起 始 值 ， 比 如 0; 
表示 x 的 结束 值 ， 比 如 100; 
表示 y 的 起 始 值 ; 


e android:fromXDelta 





e android:toXDelta 





e android:fromyY Delta 





表示 y 的 结束 值 。 


e android:toY Delta 





<scale> 标 签 表示 缩放 动画 ， 对 应 ScaleAnimation， 它 可 以 使 View 具 
有 放大 或 者 缩小 的 动画 效果 ， 它 的 一 系列 属性 的 含义 如 下 : 


水 平方 回 缩 放 的 起 始 值 ， 比 如 0.5; 

水 平方 向 缩放 的 结束 值 ， 比 如 1.2; 

坚 和 直方 同乡 放 的 起 始 值 ; 

坚 和 直方 同乡 放 的 起 始 值 ; 

缩放 的 轴 扣 的 x 坐标 ， 它 会 影响 缩放 的 效果 ; 
缩放 的 轴 反 的 y 坐 标 ， 它 会 影响 缩放 的 效果 。 





e android:fromXScale 





android:toXScale 





android:fromY Scale 


android:toY Scale 








android:pivotX 





android:pivotY 


在 <scale> 标 签 中 提 到 了 轴 扣 的 概念 ， 这 里 举 个 例子 ， 默 认 情 况 下 轴 
点 是 View 的 中 心 点 ， 这 个 时 候 在 水 平方 癌 进 行 缩放 的 话 会 导致 View 问 
左右 两 个 方 问 同时 进行 缩放 ， 但 是 如 果 把 轴 点 设 为 View 的 右边 界 ， 那 么 
View 就 只 会 问 左 边 进行 缩放 ， 反 之 则 癌 右 边 进行 缩放 ， 有 具体 效果 该 者 可 
以 自己 测试 一 下 。 


<rotate> 标 签 表 示 旋 转动 画 ， 对 于 RotateAnimation， 它 可 以 使 View 
具有 旋转 的 动画 效果 ， 它 的 属性 的 含义 如 下 : 


旋转 开始 的 角度 ， 比 如 0; 
旋转 结束 的 角度 ， 比 如 180; 
旋转 的 轴 点 的 x 坐标 ; 
旋转 的 轴 点 的 y 坐 标 。 





e android:fromDegrees 





e android:toDegrees 





e android:pivotX: 





e android:pivotY. 


在 旋转 动画 中 也 有 轴 点 的 概念 ， 它 也 会 影响 到 旋转 的 具体 效果 。 在 
旋转 动画 中 ， 轴 点 扮演 着 旋转 轴 的 角色 ， 即 View 古 围绕 着 轴 点 进行 旋转 
的 ， 默 认 情 况 下 轴 点 为 View 的 中 心 点 。 考 虑 一 种 情况 ，View 围 绕 着 自 





己 的 中 心 点 和 围绕 着 自己 的 左上 和 角 旋转 90 度 显然 是 不 同 的 旋转 轨迹 ， 不 
同 轴 点 对 旋转 效果 的 影响 读者 可 以 自己 测试 一 下 。 


<alpha> 标 签 表示 透明 度 动 画 ， 对 应 AlphaAnimation， 它 可 以 改变 
View 的 透明 度 ， 它 的 属性 的 含义 如 下 : 


表示 透明 度 的 起 始 值 ， 比 如 0.1; 
表示 透明 度 的 结束 值 ， 比 如 1。 





e android:fromAlpha 





e android:toAlpha 
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文档 。 除 了 上 面 介绍 的 属性 以 外 ，View 动 画 还 有 一 些 常用 的 属性 ， 如 下 
所 示 。 


e android:duration 动画 的 持续 时 间 ; 
e android:fillAfter 动画 结束 以 后 View 是 否 停留 在 结束 位 置 ，true 
表示 View 停 留 在 结束 位 置 ，false 则 不 停留 。 











下 面 是 一 个 实际 的 例子 : 


// res/anim/animation_ test.xml 
<?xml version="1.0" encoding="utf-8"?> 
<set xmlns:android="http://schemas.android.com/apk/res/androi 
android: fillAfter="true" 
android: zAdjustment="normal" > 
<translate 
android: duration="100" 
android: fromxDelta="0" 
android: fromyDelta="0" 


android: interpolator="@android:anim/linear_interpola 


android: toxXDelta="100" 

android: toYDelta="100" /> 
<rotate 

android: duration="400" 

android: fromDegrees="0" 

android: toDegrees="90" /> 


</set> 


如 何 应 用 上 面 的 动画 呢 ? 也 很 简单 ， 如 下 所 示 。 


Button mButton = (Button) findViewById(R.id.button1); 
Animation animation = AnimationUtils.loadAnimation(this,R.ani 
test); 


mButton.startAnimation(animation) ; 


除了 在 XML 中 定义 动画 外 ， 还 可 以 通过 代码 来 应 用 动画 ， 这 里 举 


个 例子 ， 如 下 所 示 。 


AlphaAnimation alphaAnimation = new AlphaAnimation(0,1); 
alphaAnimation.setDuration(300); 


mButton.startAnimation(alphaAnimation); 


在 上 面 的 代码 中 ， 创 建 了 一 个 透明 度 动 男 ， 将 一 个 Button 的 透 明度 





在 300ms 内 由 0 变 为 1， 人 可 以 通过 代码 来 创建 ， 这 


里 就 不 做 介绍 了 。 另 外， 通过 Animation 的 setAnimationListener 方 法 可 以 





给 View 动 画 添加 过 程 监听 ， 接 口 如 下 所 示 。 从 接口 的 定义 可 以 很 清楚 地 
看 出 每 个 方法 的 含义 。 


public static interface AnimationListener { 


void onAnimationStart(Animation animation); 
void onAnimationEnd(Animation animation); 


void onAnimationRepeat (Animation animation); 
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除了 系统 提供 的 四 种 View 动 画 外 ， 我 们 还 可 以 自 定 义 View 动 画 。 
自 定 义 动 画 是 一 件 既 简单 又 复杂 的 事情 ， 说 它 简单 ， 是 因为 派生 一 种 新 
动画 只 需要 继承 Animation 这 个 抽象 类 ， 然 后 重 写 它 的 initialize 和 
applyTransformation 方 法 ， 在 initialize 方 法 中 做 一 些 初 始 化 工作 ， 在 
applyTransformation 中 进行 相应 的 矩阵 变换 即 可 ， 很 多 时 候 需 要 采用 
Camera 来 简化 矩阵 变换 的 过 程 。 说 它 复 杂 ， 是 因为 自 定 义 View 动 画 的 
过 程 主要 是 和 矩阵 变换 的 过 程 ， 而 矩阵 变换 是 数学 上 的 概念 ， 如 果 对 这 方 
面 的 知识 不 熟悉 的 话 ， 就 会 觉得 这 个 过 程 比 较 复杂 了 。 




















本 节 不 打算 详细 地 讲解 自 定 义 View 动 画 的 细节 ， 因 为 这 都 是 数学 中 
的 矩阵 变换 的 细节 ， 读 者 只 需要 知道 自 定义 View 的 方法 并 在 需要 的 时 候 
参考 矩阵 变换 的 细节 即 可 写 出 特定 的 自 定 义 View 动 画 。 一 般 来 襄 ， 在 实 
际 开 发 中 很 少 用 到 自 定义 View 动 画 。 这 里 提供 一 个 自 定义 View 动 画 的 
例子 ， 这 个 例子 来 自 于 Android 的 ApiDemos 中 的 一 个 自 定 义 View 动 画 
Rotate3dAnimation。Rotate3dAnimation 可 以 围绕 y 轴 旋转 并 且 同 时 沿 着 z 
轴 平 移 从 而 实现 一 种 类 似 于 3D 的 效果 ， 它 的 代码 如 下 : 


public class Rotate3dAnimation extends Animation { 
private final float mFromDegrees; 


private final float mToDegrees; 


private final float mCenterx; 


private final float mCenterY; 


private final float mDepthZ; 


private final boolean mReverse; 


private Camera mCamera; 


[ris 


* Creates a new 3D rotation on the Y axis. The rotation 


* start angle and its end angle. Both angles are in deg 


* is performed around a center point on the 2D space,de 


* of X and Y coordinates,called centerX and centeryY. Wh 


* starts, 


* of the 
* should 


* @param 
* @param 
* @param 
* @param 


* @param 


a translation on the Z axis (depth) is perform 
translation can be specified,as well as whethe 


be reversed in time. 


fromDegrees the start angle of the 3D rotation 
toDegrees the end angle of the 3D rotation 
centerX the X center of the 3D rotation 
centerY the Y center of the 3D rotation 


reverse true if the translation should be reve 


otherwise 


=y 


public Rotate3dAnimation(float fromDegrees,float toDegre 


float centerX,float centerY,float depthZ, boolean 


mFromDegrees = fromDegrees; 


mToDegrees = toDegrees; 


mCenterX = centerX; 


mCenterY = centerY; 





camera.getMatrix(matrix); 
Ccamera.restore(); 
matrix.preTranslate(-centerX, -centeryY); 


matrix.postTranslate(centerX,centeryY); 
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帧 动画 是 顺序 播放 一 组 预先 定义 好 的 图 片 ， 类 似 于 电影 播放 。 不 同 
于 View 动 画 ， 系 统 提 供 了 另外 一 个 类 AnimationDrawable 来 使 用 帧 动 
画 。 帧 动画 的 使 用 比较 简单 ， 首 先 需 要 通过 XML 来 定义 一 个 
AnimationDrawable， 如 下 所 示 。 


// vres/drawable/frame_animation. xml 

<?xml version="1.0" encoding="utf-8"?> 

<animation-list xmlns:android="http://schemas.android.com/apk 
android: oneshot="false"> 
<item android: drawable="@drawable/imagei" android:durati 
<item android: drawable="@drawable/image2" android:durati 
<item android: drawable="@drawable/image3" android:durati 


</animation-list> 


然后 将 上 述 的 Drawable 作 为 View 的 背景 并 通过 Drawable 来 播放 动画 


Button mButton = (Button)findViewById(R.id.button1); 


mButton.setBackgroundResource(R.drawable.frame_animation) ; 


AnimationDrawable drawable = (AnimationDrawable) mButton.getB 


drawable.start(); 


帧 动画 的 使 用 比较 简 蛙 ,但 是 比较 容易 引起 OOM， 所 以 在 使 用 帧 
动画 时 应 尽量 避免 使 用 过 多 尺寸 较 大 的 图 片 。 


7.2 View 动 国 的 特殊 使 用 场景 


在 7.1 节 中 我 们 介绍 了 View 动 画 的 四 种 形式 ， 除 了 这 四 种 形式 外 ， 
View 动 画 还 可 以 在 一 些 特殊 的 场景 下 使 用 ， 比 如 在 ViewGroup 中 可 以 控 
制 子 元 素 的 出 场 效 果 ， 在 Activity 中 可 以 实现 不 同 Activity 之 间 的 切换 效 
果 。 


7.2.1 LayoutAnimation 


LayoutAnimation 作 用 于 ViewGroup， 为 ViewGroup 指 定 一 个 动画 ， 
这 样 当 它 的 子 元 素 出 场 时 都 会 具有 这 种 动画 效果 。 这 种 效果 津津 被 用 在 
ListView 上 ， 我 们 时 常会 看 到 一 种 特殊 的 ListYiew， 它 的 每 个 item 都 以 
一 定 的 动画 的 形式 出 现 ， 其 实 这 并 非 什 么 高 深 的 技术 ， 它 使 用 的 就 是 
LayoutAnimation。LayoutAnimation 也 是 一 个 View 动 画 ， 为 了 给 


ViewGroup 的 子 元 素 加 上 出 场 效 果 ， 遵 循 如 下 几 个 步骤 。 
(1) 定义 LayoutAnimation， 如 下 所 示 。 


// res/anim/anim_layout . xml 

<layoutAnimation 
xmins:android="http://schemas.android.com/apk/res/androi 
android: delay="0.5" 
android: animationOrder="normal" 


android: animation="@anim/anim_item"/> 


它 的 属性 的 含义 如 下 所 示 。 


android:delay 
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为 300ms， 那 么 0.5 表 示 每 个 子 元 素 都 需要 延迟 150ms 才 能 播放 入 场 动 
画 。 总 体 来 说 ， 第 一 个 子 元 素 延 迟 150ms 开 始 播放 入 场 动 画 ， 第 2 个 子 元 
素 延 迟 300ms 开 始 播放 入 场 动画 ， 依 次 类 推 。 








android:animationOrder 








表示 子 元 素 动画 的 顺序 ， 有 三 种 选项 ;normal、reverse 和 random， 
其 中 normal 表 示 顺 序 显 示 ， 即 排 在 前 面 的 和子 元 素 先 开始 播放 入 场 动画 ; 
reverse 表 示 逆 问 显 示 ， 即 排 在 后 面 的 子 元 素 先 开始 播放 入 场 动画 ; 
random 则 是 随机 播放 入 场 动画 。 





android:animation 





为 子 元 系 指 定 具 体 的 入 场 动画 。 





D 为 子 元 素 指 定 具 体 的 入 场 动画 ， 如 下 所 示 。 


// res/anim/anim item.xml 
<?xml version="1.0" encoding="utf-8"?> 
<set xmlns:android="http://schemas.android.com/apk/res/androi 
android: duration="300" 
android: interpolator="@android:anim/accelerate_interpola 
android: shareInterpolator="true" > 
<alpha 
android: fromAlpha="0.0" 


android: toAlpha="1.0" /> 
<translate 

android: fromxXDelta="500" 

android: toxXDelta="0" /> 


</set> 


(3) 为 ViewGroup 指 定 android:layoutAnimation 属 性 : 
android:layoutAnimation= "@anim/ anim_layout"。 对 于 ListView 来 说 ， 这 
样 ListView 的 item 就 具有 出 场 动画 了 ， 这 种 方式 适用 于 所 有 的 
ViewGroup， 如 下 所 示 。 





<ListView 
android: id="@+id/list" 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android: LayoutAnimation="@anim/anim_layout" 
android: background="#fff4F7f9" 
android: cacheColorHint="#00000000" 
android: divider="#dddbdb" 
android: dividerHeight="1.0px" 


android: listSelector="@android:color/transparent" /> 


除了 在 XML 中 指定 LayoutAnimation 外 ， 还 可 以 通过 
LayoutAnimationController 来 实现 ， 有 具体 代码 如 下 所 示 。 


ListView listView = (ListView) layout.findViewById(R.id.list) 
Animation animation = AnimationUtils.loadAnimation(this,R.ani 


item); 


LayoutAnimationController controller = new LayoutAnimationCon 
(animation); 

controller.setDelay(0.5f); 

controller.setOrder(LayoutAnimationController .ORDER_NORMAL ) ; 


listView.setLayoutAnimation(controller); 


7.2.2 ” Activity 的 切换 效果 


Activity 有 默认 的 切换 效果 ， 但 是 这 个 效果 我 们 是 可 以 自 定义 的 ， 
主要 用 到 overridePendingTransition(int enterAnim,int ”exitAnim) 这 个 方 
法 ， 这 个 方法 必须 在 startActivity(Intenb) 或 者 finish0 之 后 被 调用 才能 
效 ， 它 的 参数 含义 如 下 : 


Activity 被 打开 时 ， 所 需 的 动画 资源 id; 
Activity 被 暂停 时 ， 所 需 的 动画 资源 id。 


e enterAnim 





e exitAnim 





当局 动 一 个 Activity 时 ， 可 以 按照 如 下 方式 为 其 添加 目 定义 的 切换 
BR : 


Intent intent = new Intent(this, TestActivity.class); 
startActivity(intent); 


overridePendingTransition(R.anim.enter_anim,R.anim.exit_anim) 


当 Activity 退 出 时 ， 也 可 以 为 其 指定 自己 的 切换 效果 ， 如 下 所 示 。 


@Override 
public void finish() { 


super.finish(); 


overridePendingTransition(R.anim.enter_anim,R.anim.exit_a 


} 


需要 注意 的 是 ，overridePendingTransition 这 个 方法 必须 位 于 


startActivity 或 者 finish 的 后 面 ， 人 否则 动画 效果 将 不 起 作用 。 





Fragment 也 可 以 添加 切换 动画 ， 由 于 Fragment 是 在 API 11 中 新 引入 
的 类 ， 因 此 为 了 兼容 性 我 们 需要 使 用 support-v4 这 个 兼容 包 ， 在 这 种 情 
况 下 我 们 可 以 通过 FragmentTransaction 中 的 setCustomAnimations() 方 法 来 
添加 切换 动画 。 这 个 切换 动画 需要 是 View 动 画 ， 之 所 以 不 能 采用 属性 动 
国 是 因为 属性 动画 也 是 API 11 新 引入 的 。 还 有 其 他 方式 可 以 给 Activity 和 
Fragment 添 加 切换 动画 ， 但 是 它们 大 多 都 有 兼容 性 问题 ， 在 低 版 本 上 无 
法 使 用 ， 因 此 不 具有 很 高 的 使 用 价值 ， 这 里 就 不 再 一 一 介绍 了 。 








7.3 ”属性 动画 


属性 动画 是 API 11 新 加 入 的 特性 ， 和 View 动 画 不 同 ， 它 对 作用 对 象 
进行 了 扩展 ， 属 性 动画 可 以 对 任何 对 象 做 动画 ， 甚 至 还 可 以 没有 对 象 。 
除了 作用 对 象 进行 了 扩展 以 外 ， 属 性 动画 的 效果 也 得 到 了 加 强 ， 不 再 像 
View 动 画 那样 只 能 文 持 四 种 简单 的 变换 。 属 性 动画 中 有 
ValueAnimator、ObjectAnimator 和 AnimatorSet 等 概念 ， 通 过 它们 可 以 实 
现 绚丽 的 动画 。 


7.3.1 使 用 属性 动画 


属性 动画 可 以 对 任意 对 象 的 属性 进行 动画 而 不 仅仅 是 View， 动 画 默 
认 时 间 间 隔 300ms， 默 认 帧 率 10ms/ 帧 。 其 可 以 达到 的 效果 是 : 在 一 个 时 
间 间 隔 内 完成 对 象 从 一 个 属性 值 到 另 一 个 属性 值 的 改变 。 因 此 ， 属 性 动 
画 几 乎 是 无 所 不 能 的 ， 只 要 对 象 有 这 个 属性 ， 它 都 能 实现 动画 效果 。 但 
是 属性 动画 从 API 11 才 有 ， 这 束 严 重 制约 了 属性 动画 的 使 用 。 可 以 采用 
开源 动画 库 nineoldandroids 来 兼容 以 前 的 版 本 ， 采 用 nineoldandroids， 可 
以 在 API ”11 以 前 的 系统 上 使 用 属性 动画 ，nineoldandroids 的 网 址 是 : 


http://nineoldandroids.com. 



































Nineoldandroids 对 属性 动画 做 了 兼容 ， 在 API 11 以 前 的 版 本 其 内 部 
是 通过 代理 View 动 画 来 实现 的 ， 因 此 在 Android 低 版 本 上 ， 它 的 本 质 还 
是 View 动 画 ， 尽 管 使 用 方法 看 起 来 是 属性 动画 。Nineoldandroids 的 功能 
和 系统 原生 对 的 android.animation.* 中 类 的 功能 完全 一 致 ， 使 用 方法 也 完 
全 一 样 ， 只 要 我 们 用 nineoldandroids 来 编写 动画 ， 就 可 以 在 所 有 的 


Android 系 统 上 运行 。 比 较 常 用 的 几 个 动画 类 是 : ValueAnimator、 
ObjectAnimator 和 AnimatorSet， 其 中 ObjectAnimator 继 承 目 
ValueAnimator，AnimatorSet 是 动画 集合 ， 可 以 定义 一 组 动画 ， 它 们 使 
用 起 来 也 是 极其 简单 的 。 如 何 使 用 属性 动画 呢 ? 下 面 简单 举 几 个 小 例 
子 ， 读 者 一 看 就 明白 了 。 


(1) 改变 一 个 对 象 myObject) 的 translationY 属 性 ， 让 其 沿 着 Y 轴 
癌 上 平移 一 段 距离 : 它 的 高 度 ， 该 动画 在 默认 时 间 内 完成 ， 动 画 的 完成 
时 间 是 可 以 定义 的 。 想 要 更 灵活 的 效果 我 们 还 可 以 定义 插值 器 和 估 值 算 
法 ， 但 是 一 般 来 说 我 们 不 需要 自 定义 ， 系 统 已 经 预 置 了 一 些 ， 能 够 满足 
常用 的 动画 。 





ObjectAnimator .ofFloat(my0bject,"translationY", -myObject.getH 
start(); 


(2) 改变 一 个 对 象 的 背景 色 属 性 ， 典 型 的 情形 是 改变 View 的 背景 
色 ， 下 面 的 动画 可 以 让 背景 色 在 3 秒 内 实现 从 0xFFFF8080 到 0xFF8080FF 
的 渐变 ， 动 画 会 无 限 循环 而 且 会 有 反 转 的 效果 。 





ValueAnimator colorAnim = ObjectAnimator.ofInt(this, "backgrou 
/*Red*/OxXFFFF8080, /*Blue*/OXFF8080FF ) ; 

colorAnim. setDuration( 3000) ; 

colorAnim.setEvaluator(new ArgbEvaluator()); 

colorAnim.setRepeatCount (ValueAnimator.INFINITE) ; 

colorAnim. setRepeatMode(ValueAnimator .REVERSE) ; 


colorAnim.start(); 


(3) 动画 集合 ，5 秒 内 对 View 的 旋转 、 平 移 、 缩 放 和 透明 上 度 都 进行 


TIRE: 


AnimatorSet set = new AnimatorSet(); 

set.playTogether ( 
ObjectAnimator.ofFloat(myView, "rotationx",0, 360), 
ObjectAnimator.ofFloat(myView, "rotationY", 0,180), 
ObjectAnimator .ofFloat(myView, "rotation", 0, -90), 
ObjectAnimator .ofFloat(myView, "translationx",0,90), 
ObjectAnimator .ofFloat(myView, "translationY", 0,90), 
ObjectAnimator .ofFloat(myView, "scalex",1,1.5f), 
ObjectAnimator .ofFloat(myView, "scaleY",1,0.5f), 
ObjectAnimator .ofFloat(myView, "alpha",1,0.25f,1) 

); 
set.setDuration(5 * 1000).start(); 


属性 动画 除了 通过 代码 实现 以 外 ， 还 可 以 通过 XML 来 定义 。 属 性 
动画 需要 定义 在 res/animator/ 目 录 下 ， 它 的 语法 如 下 所 示 。 





<set 
android:ordering=["together" | "sequentially"]> 
<objectAnimator 
android:propertyName="string" 
android:duration="int" 
android:valueFrom="float | int | color" 
android:valueTo="float | int | color" 
android:startoffset="int" 
android:repeatCount="int" 


android:repeatMode=["repeat" | "reverse" ] 


android: valueType=["intType" | "floatType"]/> 
<animator 

android: duration="int" 

android: valueFrom="float | int | color" 

android: valueTo="float | int | color" 

android: startoffset="int" 


android: repeatCount="int" 


android: repeatMode=["repeat" | "reverse" ] 
android: valueType=["intType" | "floatType"]/> 
<set> 
</set> 


</set> 


属性 动画 的 各 种 参数 都 比较 好 理解 ， 在 XML 中 可 以 定义 
ValueAnimator、Object-Animator 以 及 AnimatorSet， 其 中 <set> 标 签 对 应 
AnimatorSet，<Animator> 标 签 对 应 ValueAnimator， 而 <objectAnimator> 
则 对 应 ObjectAnimator。<set> 标 和 俭 的 android:ordering 属 性 有 两 个 可 选 
值 : “together” 和 “sequentially”， 其 中 “together 表 示 动 画集 合 中 的 子 动画 
同时 播放 , “sequentially” 则 表示 动画 集合 中 的 子 动画 按照 前 后 顺序 依次 
播放 ，android:ordering 属 性 的 默认 值 是 “together”。 








对 于 <objectAnimator> 标 签 的 各 个 属性 的 含义 ， 下 面 简 单 说 明 一 
下 ， 对 于 <Animator> 标 俭 这 里 就 不 再 介绍 了 ， 因 为 它 只 是 比 
<objectAnimator> 少 了 一 个 android:propertyName 必 性 而 已 ， 其 他 都 是 一 
样 的 。 





表示 属性 动画 的 作用 对 象 的 属性 的 名 称 ; 


e android:propertyName 


表示 动画 的 时 长 ; 

表示 属性 的 起 始 值 ; 

表示 属性 的 结束 值 ; 

android:startOffset 一 一 表示 动画 的 延迟 时 间 ， 当 动画 开始 后 ， 需 要 

延迟 多 少 坚 秒 才 会 真正 播放 此 动画 ; 

表示 动画 的 重复 次 数 ; 

表示 动画 的 重复 模式 ; 

e android:valueType 一 一 表示 android:propertyName 所 指定 的 属性 的 类 
型 ， 有 “intType” 和 “floatType” 两 个 可 选项 ， 分 别 表示 属性 的 类 型 为 
整 型 和 浮 点 型 。 另 外 ， 如 果 android:propertyName 所 指定 的 属性 表示 
的 是 颜色 ， 那 么 不 需要 指定 android:valueType， 系 统 会 自动 对 颜色 
类 型 的 属性 做 处 理 。 


android:duration 





android:valueFrom: 





e android:valueTo 








e android:repeatCount 





e android:repeatMode 








对 于 一 个 动画 来 说 ， 有 两 个 属性 这 里 要 特殊 说 明 一 下 ， 一 个 是 
android:repeatCount， 它 表示 动画 循环 的 次 数 ， 默 认 值 为 0%， 其 中 -1 表示 
无 限 循环 ， 另 一 个 是 android:repeatMode， 它 表示 动画 循环 的 模式 ， 有 两 
个 选项 : “repeat” 和 “reverse”， 分 别 表 示 连 续 重 复 和 逆向 重复 。 连 续 重 复 
比较 好 理解 ， 就 是 动画 每 次 都 重新 开始 播放 ， 而 逆 同 重复 是 指 第 一 次 播 
放 完 以 后 ， 第 二 次 会 倒 着 播放 动画 ， 第 三 次 再 重头 开始 播放 动画 ， 第 四 
次 再 倒 着 播放 动画 ， 如 此 反复 。 











下 面 是 一 个 具体 的 例子 ， 我 们 通过 XML 定 义 一 个 属性 动画 并 将 其 
作用 在 View 上 ， 如 下 所 示 。 


// ves/animator/property_animator. xml 
<set android: ordering="together'"> 
<objectAnimator 


android: propertyName="x" 


android: duration="300" 
android: valueTo="200" 
android: valueType="intType"/> 
<objectAnimator 
android: propertyName="y" 
android: duration="300" 
android: valueTo="300" 
android: valueType="intType"/> 


</set> 


如 何 使 用 上 面 的 属性 动画 呢 ? 也 很 简单 ， 如 下 所 示 。 


AnimatorSet set = (AnimatorSet) AnimatoriInflater.loadAnimator 
R.anim.property_animator ); 

set.setTarget(mButton); 

set.start(); 





在 实际 开发 中 建议 采用 代码 来 实现 属性 动画 ， 这 是 因为 通过 代码 来 
实现 比较 简单 。 更 重要 的 是 ， 很 多 时 候 一 个 属性 的 起 始 值 是 无 法 提前 确 
定 的 ， 比 如 让 一 个 Button 从 屏幕 左边 移动 到 屏幕 的 右边 ， 由 于 我 们 无 法 
提前 知道 屏幕 的 宽度 ， 因 此 无 法 将 属性 动画 定义 在 XML 中 ， 在 这 种 情 
况 下 就 必须 通过 代码 来 动态 地 创建 属性 动画 。 


7.3.2 FETE as FAB as 
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的 百分比 来 计算 出 当前 属性 值 改变 的 百分比 ， 系 统 预 置 的 有 

















LinearInterpolator (IEM E4: 勾 速 动画 ) 、 
AccelerateDecelerateInterpolator 〈 加 速 减 速 插值 器: 动画 两 头 慢 中 间 

快 ) 和 Decelerate-Interpolator (减速 插值 器 : 动画 越 来 越 慢 ) 等 
TypeEvaluator 的 中 文 翻 译 为 类 型 估 值 算法 ， 也 叫 估 值 器 ， 它 的 作用 是 根 
据 当 前 属性 改变 的 百分比 来 计算 改变 后 的 属性 值 ， 系 统 预 置 的 有 
IntEvaluator 〈 针 对 整 型 属性 ) 、FloatEvaluator〈 针 对 浮 点 型 属性 ) 和 
ArgbEvaluator 〈 针 对 Color 属 性 ) 。 属 性 动画 中 的 插值 器 (Interpolator) 
和 估 值 占 (TypeEvaluator) 很 重要 ， 它 们 是 实现 非 匀速 动画 的 重要 手 
段 。 可 能 这 么 说 还 有 点 星 深 ， 没 关系 ， 下 面 给 出 一 个 实例 就 很 好 理解 
E 
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值 算法 ， 在 40ms 内 ，View 的 x 属性 实现 从 0 到 40 的 变换 。 


x=0 X= x= 40 
t= Oms t= t=40ms 


图 7-1 +BY LHR CE: 此 图 来 自 Android 官 方 文档 ) 








由 于 动画 的 默认 刷新 率 为 10ms/ 帧 ， 所 以 该 动画 将 分 5 帧 进行 ， 我 们 
来 考虑 第 三 帧 Cx=20, t=20ms) ， 当 时 间 t=20ms 的 时 候 ， 时 间 流 逝 的 百 
分 比 是 0.5〈20/40=0.5) ， 意 味 着 现在 时 间 过 了 一 半 ， 那 x 应 该 改变 多 少 
呢 ? 这 个 就 由 搬 值 器 和 估 值 算法 来 确定 。 拿 线性 插值 器 来 说 ， 当 时 间 流 
逝 一 半 的 时 候 ，x 的 变换 也 应 该 是 一 半 ， 即 x 的 改变 是 0.5， 为 什么 呢 ? 
因为 它 是 线性 插值 器 ， 是 实现 匀速 动画 的 ， 下 面 看 它 的 源码 : 





public class LinearInterpolator implements Interpolator { 
public LinearInterpolator() { 
} 
public LinearInterpolator(Context context,AttributeSet a 
} 
public float getInterpolation(float input) { 


return input; 


} 
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是 0.5， 这 意味 看 x 的 改变 是 0.5， 这 个 时 候 插 值 费 的 工作 不 完成 了 。 具 体 
x 变 成 了 什么 值 ， 这 个 需要 佑 值 算法 来 确定 ， 我 们 来 看 看 整 型 佑 值 算法 
的 源码 : 





public class IntEvaluator implements TypeEvaluator<Integer> { 
public Integer evaluate(float fraction,Integer startValu 
endValue) { 
int startInt = startValue; 


return (int)(startInt + fraction * (endValue -startI 


} 


上 述 算 法 很 简单 ，evaluate 的 三 个 参数 分 别 表 示 估 值 小 数 、 开 始 值 
和 结束 值 ， 对 应 于 我 们 的 例子 就 分 别 是 0.5、0、40。 根 据 上 述 算 法 ， 整 
型 估 值 返回 给 我 们 的 结果 是 20， 这 就 是 (x=20，t=20ms) 的 由 来 。 





属性 动画 要 求 对 象 的 该 属性 有 set 方 法 和 get 方 法 (可 选 ) 。 插 值 器 





和 估 值 算法 除了 系统 提供 的 外 ， 我 们 还 可 以 自 定义 。 实 现 方式 也 很 简 
单 ， 因 为 插值 器 和 估 值 算法 都 是 一 个 接口 ， 且 内 部 都 只 有 一 个 方法 ， 我 
们 只 要 派生 一 个 类 实现 接口 束 可 以 了 ， 然 后 就 可 以 做 出 干 奇 百 怪 的 动画 
效果 了 。 具 体 一 点 就 是 自 定义 插值 器 需要 实现 Interpolator 或 者 
TimeInter-polator， 目 定义 估 值 算法 需要 实现 TypeEvaluator。 另 外 就 是 如 
果 要 对 其 他 类 型 〈 非 int、float、Color) 做 动画 ， 那 么 必须 要 自 定 义 类 型 
估 值 算法 。 


7.3.3 ”属性 动画 的 监听 覆 


属性 动画 提供 了 监听 器 用 于 监听 动画 的 播放 过 程 ， 主 要 有 如 下 两 个 


接口 : AnimatorUpdateListener 和 AnimatorListener。 








AnimatorListener 的 定义 如 下 : 


public static interface AnimatorListener { 
void onAnimationStart(Animator animation); 
void onAnimationEnd(Animator animation); 
void onAnimationCancel(Animator animation); 
void onAnimationRepeat(Animator animation); 


$ 


从 AnimatorListener 的 定义 可 以 看 出 ， 它 可 以 监 昕 动画 的 开始 、 结 
束 、 取 消 以 及 重复 播放 。 同 时 为 了 方便 开发 ， 系 统 还 提供 了 
AnimatorListenerAdapter 这 个 类 ， 它 是 Animator-Listener 的 适配器 类 ， 这 
样 我 们 就 可 以 有 选择 地 实现 上 面 的 4 个 方法 了 ， 毕 竟 不 是 所 有 方法 都 是 
我 们 感 兴趣 的 。 








下 面 再 看 一 下 AnimatorUpdateListener 的 定义 ， 如 下 所 示 。 


public static interface AnimatorUpdateListener { 
void onAnimationUpdate(ValueAnimator animation); 


} 


AnimatorUpdateListener 比 较 特 殊 ， 它 会 监听 整个 动画 过 程 ， 动 画 是 
由 许多 帧 组 成 的 ， 每 播放 一 帧 ，onAnimationUpdate 就 会 被 调用 一 次 ， 利 
用 这 个 特性 ， 我 们 可 以 做 一 些 特殊 的 事情 。 


7.3.4 ”对 任意 属性 做 动画 


这 里 先 提出 一 个 问题 ， 给 Button 加 一 个 动画 ， 让 这 个 Button 的 宽度 
从 当前 宽度 增加 到 500px。 也 许 你 会 说 ， 这 很 简单 ， 用 View 动 画 就 可 以 
搞定 ， 我 们 可 以 来 试 试 ， 你 能 写 出 来 吗 ? 很 快 你 就 会 居然 大 悟 ， 原 来 
View 动 画 根 本 不 支持 对 宽度 进行 动画 。 没 错 ，View 动 画 只 文 持 四 种 类 
型 : 平移 (Translate) 、 旋 转 (Rotate) 、 缩 放 〈Scale) 、 不 透明 度 
(Alpha) 。 当 然 用 x 方 向 缩放 (CscaleX) 可 以 让 Button 在 x 方 向 放大 ， 看 
起 来 好 像 是 宽度 增加 了 ， 实 际 上 不 是 ， 只 是 Button 被 放大 了 而 已 ， 而 且 
由 于 只 x 方向 被 放大 ， 这 个 时 候 Button 的 缘 景 以 及 上 面 的 文本 都 被 拉 伸 
了 ， 甚 至 有 可 能 Button 会 超出 屏幕 ， 如 图 7-2 所 示 。 

















168) 于 安 4H 


图 7-2 属性 动画 的 缩放 效果 








图 7-2 中 的 效果 显然 是 很 过 的 ， 而 且 也 不 是 真正 地 对 宽度 做 动 国 ， 
不 过 ， 所 笠 我 们 还 有 属性 动画 ， 我 们 用 属性 动画 试 试 ， 如 下 所 示 。 


private void performAnimate() { 
ObjectAnimator.ofInt(mButton, "width", 500) .setDuration(500 
j 
@Override 
public void onClick(View v) { 
if (v == mButton) { 


performAnimate(); 


} 


上 述 代码 运行 后 发 现 没 效果 ， 其 实 没 效果 是 对 的 ， 如 果 随 便 传递 一 
个 属性 过 去 ， 轻 则 没 动画 效果 ， 重 则 程序 直接 Crash。 


下 面 分 析 属 性 动画 的 原理 : 属性 动画 要 求 动画 作用 的 对 象 提供 该 属 
性 的 get 和 和 set 方法 ， 属 性 动画 根据 外 界 传 递 的 该 属性 的 初始 值 和 最 终 
值 ， 以 动画 的 效果 多 次 去 调用 set 方 法 ， 每 次 传递 给 set 方 法 的 值 都 不 一 
样 ， 确 切 来 说 是 随 着 时 间 的 推移 ， 所 传递 的 值 越 来 越 接 近 最 终 值 。 总 结 





一 下 ， 我 们 对 object 的 属性 abc 做 动画 ， 如 果 想 让 动画 生效 ， 要 同时 满足 
两 个 条 件 ; 


(1) object 必 须要 提供 setAbc 方 法 ， 如 果 动 画 的 时 候 没 有 传递 初始 
值 ， 那 么 还 要 提供 getAbc 方 法 ， 因 为 系统 要 去 取 abc 属 性 的 初始 值 〈 如 
果 这 条 不 满足 ， 程 序 直接 Crash) 。 





(2) object 的 setAbc 对 属性 abc 所 做 的 改变 必须 能 够 通过 某 种 方法 反 
映 出 来 ， 比 如 会 带 来 UI 的 改变 之 类 的 (如 果 这 条 不 满足 ， 动 画 无 效果 但 
不 会 Crash) 。 


以 上 条 件 缺 一 不 可 。 那 么 为 什么 我 们 对 Button 的 width 属性 做 动画 会 
没有 效果 ? 这 是 因为 Button 内 部 虽然 提供 了 getWidth 和 setWidth 方 法 ， 但 
是 这 个 setWidth 方 法 并 不 是 改变 视图 的 大 小 ， 它 是 TextView 新 添加 的 方 
法 ，View 是 没有 这 个 setWidth 方 法 的 ， 由 于 Button 继 承 了 TextView， 所 
以 Button 也 束 有 了 setWidth 方 法 。 下 面 看 一 下 这 个 getWidth 和 setWidth 方 
法 的 源码 : 


As: 
* Makes the TextView exactly this many pixels wide. 


* You could do the same thing by specifying this number in 


* 


LayoutParams. 


* @see #setMaxWidth(int) 
* @see #setMinWidth(int) 
* @see #getMinWidth() 
* @see #getMaxWidth( ) 


* @attr ref android.R.styleable#TextView_width 
a 
@android.view.RemotableViewMethod 
public void setWidth(int pixels) { 
mMaxWidth = mMinWidth = pixels; 
mMaxwidthMode = mMinWidthMode = PIXELS; 
requestLayout(); 
invalidate(); 
t 
/** 
* Return the width of the your view. 


* 


* @return The width of your view,in pixels. 

wee 
@ViewDebug.ExportedProperty(category = "layout" ) 
public final int getWidth() { 


return mRight -mLeft; 


从 上 述 源码 可 以 看 出 ，getWidth 的 确 是 获取 View 的 宽度 的 ， 而 
setWidth 是 TextView 和 其 子 类 的 专属 方法 ， 它 的 作用 不 是 设置 View 的 帘 
度 ， 而 是 设置 TextView 的 最 大 宽度 和 最 小 宽度 的 ， 这 个 和 TextView 的 宽 
度 不 是 一 个 东西 。 有 具体 来 说 ，TextView 的 宽度 对 应 XML 中 的 
android:layout_ width 属性 ， 而 TextView 还 有 一 个 属性 android:width， 这 
个 android:width 属 性 就 对 应 了 TextView 的 setWidth 方 法 。 总 之 ， 
TextView 和 Button 的 setWidth、getWidth 干 的 不 是 同一 件 事情 ， 通 过 
setWidth 无 法 改变 控件 的 宽度 ， 所 以 对 width 做 属性 动画 没有 效果 。 对 应 











于 属性 动画 的 两 个 条 件 来 说 ， 本 例 中 动画 不 生效 的 原因 是 只 满足 了 条 件 
1 而 未 满足 条 件 2。 
针对 上 述 问 题 ， 官 方 文档 上 告诉 我 们 有 3 种 解决 方法 : 


。 给 你 的 对 象 加 上 get 和 set 方 法 ， 如 果 你 有 权限 的 话 ; 
。 用 一 个 类 来 包装 原始 对 象 ， 则 接 为 其 提供 get 和 set 方 法 ; 
。 采用 ValueAnimator， 监 听 动 画 过 程 ， 目 己 实 现 属性 的 改变 。 





针对 上 面 提出 的 三 种 解决 方法 ， 下 面 给 出 具体 的 介绍 。 
1. 给 你 的 对 象 加 上 get 和 set 方 法 ， 如 果 你 有 权限 的 话 


这 个 的 意思 很 好 理解 ， 如 果 你 有 权限 的 话 ， 加 上 get 和 set 就 搞定 
了 。 但 是 很 多 时 候 我 们 没 权 限 去 这 么 做 。 比 如 本 文 开头 所 提 到 的 问题 ， 
你 无 法 给 Button 加 上 一 个 合乎 要 求 的 setWidth 方 法 ， 因 为 这 是 Android 
SDK 内 部 实现 的 。 这 个 方法 最 简单 ， 但 是 往往 是 不 可 行 的 ， 这 里 就 不 对 
其 进行 更 多 的 分 析 了 。 











2. 用 一 个 类 来 包装 原始 对 象 ， 间 接 为 其 提供 get 和 set 方 法 


这 是 一 个 很 有 用 的 解决 方法 ， 是 笔者 最 喜欢 用 的 ， 因 为 用 起 来 很 方 
便 ， 也 很 好 理解 ， 下 面 将 通过 一 个 具体 的 例子 来 介绍 它 。 


private void performAnimate() { 
ViewWrapper wrapper = new ViewWrapper(mButton) ; 
ObjectAnimator.ofiInt(wrapper, "width", 500) .setDuration(500 
t 
@Override 


public void onClick(View v) { 





上 述 代 码 在 5s 内 让 Button 的 宽度 
增加 到 了 500px， 为 了 达到 这 个 效 
果 ， 我 们 提供 了 ViewWrapper 类 专门 
用 于 包装 View， 具 体 到 本 例 是 包装 
Button。 然 后 我 们 对 ViewWrapper 的 
width 属性 做 动画 ， 并 且 在 setWidth 方 图 7-3 属性 动画 对 宽度 做 动画 的 效果 
法 中 修改 其 内 部 的 target 的 宽度 ， 而 
target 实 际 上 就 是 我 们 包装 的 Button。 这 样 一 个 间接 属性 动画 就 搞定 了 ， 
上 述 代 码 同 样 适用 于 一 个 对 象 的 其 他 属性 。 如 图 7-3 所 示 ， 很 显然 效果 





达到 了 ， 真 正 实 现 了 对 宽度 做 动画 。 


3. 采用 ValueAnimator， 监 听 动 画 过 程 ， 上 自己 实现 属性 的 改变 





首先 说 说 什么 是 ValueAnimator，ValueAnimator 本 身 不 作用 于 任何 











对 象 ， 也 就 是 说 直接 使 用 它 没有 任何 动画 效果 。 筷 可 以 对 一 个 值 做 动 
画 ， 然 后 我 们 可 以 监听 其 动画 过 程 ， 在 动画 过 程 中 修改 我 们 的 对 象 的 局 
性 值 ， 这 样 也 就 相当 于 我 们 的 对 象 做 了 动画 。 下 面 用 例子 来 说 明 : 








private void performAnimate(final View target,final int start 


end) { 


ValueAnimator valueAnimator = ValueAnimator.ofiInt(1,100); 


valueAnimator.addUpdateListener(new AnimatorUpdateListene 


+); 





// 持 有 一 个 IntEValLuator 对 象 ， 方 便 下 面 估 值 的 时 候 使 用 
private IntEvaluator mEvaluator = new IntEvaluato 
@Override 


public void onAnimationUpdate(ValueAnimator anima 


// 获得 当前 动画 的 进度 值 ， 整 型 ，1~100 之 间 

int currentValue = (Integer) animator.get. 
Log.d(TAG, "Current value: " + currentValu 
// 获得 当前 进度 占 整个 动画 过 程 的 比例 ， 浮 点 型 ，0~1 
float fraction = animator.getAnimatedFrac 
// 直接 调用 整 型 估 值 器 ， 通 过 比例 计算 出 宽度 ， 然 后 再 
target.getLayoutParams().width = mEvaluat 


target.requestLayout(); 


valueAnimator.setDuration(5000).start(); 


ji 
@Override 
public void onClick(View v) { 
if (v == mButton) { 
performAnimate(mButton, mButton.getWidth(),500); 


} 


上 述 代码 的 效果 图 和 采用 ViewWrapper 是 一 样 的 ， 请 参看 图 7-3。 关 
于 这 个 ValueAnimator 要 再 说 一 下 ， 拿 上 面 的 例子 来 说 ， 它 会 在 5000mas 
内 将 一 个 数 从 1 变 到 100， 然 后 动画 的 每 一 帧 会 回调 onAnimationUpdate 方 
法 。 在 这 个 方法 里 ， 我 们 可 以 获取 当前 的 值 1 一 100) 和 当前 值 所 占 的 
比例 ， 我 们 可 以 计算 出 Button 现 在 的 宽度 应 该 是 多 少 。 比 如 时 间 过 了 一 
半 ， 当 前 值 是 50， 比 例 为 0.5， 假 设 Button 的 起 始 宽度 是 100px， 最 终 宽 
上 度 是 500px， 那 么 Button 增 加 的 宽度 也 应 该 占 总 增加 宽度 的 一 半 ， 总 增 
加 宽度 是 500 一 100=400， 所 以 这 个 时 候 Button 应 该 增加 的 宽度 是 
400x0.5=200， 那 么 sneer 应 该 为 初始 宽度 + ”增加 宽度 
(100+200=300) 。 上 述 计算 过 程 很 简单 ， 其 实 它 就 是 整 型 估 值 器 
IntEvaluator 的 ae 所 以 我 们 不 用 自己 写 了 ， 直 接 用 吧 。 


7.3.5 属性 动画 的 工作 原理 


属性 动画 要 求 动画 作用 的 对 象 提供 该 属性 的 set 方 法 ， 属 性 动画 根据 
你 传递 的 该 属性 的 初始 值 和 最 终 值 ， 以 动画 的 效果 多 次 去 调用 set 方 法 。 
每 次 传递 给 set 方 法 的 值 都 不 一 样 ， 确 切 来 说 是 随 着 时 间 的 推移 ， 所 传递 
的 值 越 来 越 接 近 最 终 值 。 如 果 动 画 的 时 候 没 有 传递 初始 值 ， 那 么 还 要 所 











供 get 方 法 ， 因 为 系统 要 去 获取 属性 的 初始 值 。 对 于 属性 动画 来 说 ， 其 
动 国 过 程 中 所 做 的 就 是 这 么 多 ， 下 面 看 源码 分 析 。 


首先 我 们 要 找 一 个 入 口 ， 就 从 
ObjectAnimator.ofInt(mButton, "width",500).setDuration (5000).start()It 
台 ， 其 他 动画 都 是 类 似 的 。 先 看 ObjectAnimator 的 start 方 法 : 


public void start() { 
// See if any of the current active/pending animators nee 
AnimationHandler handler = sAnimationHandler.get(); 
if (handler != null) { 
int numAnims = handler.mAnimations.size(); 
for (int i = numAnims -1; i => 0; i--) { 
if (handler.mAnimations.get(i) instanceof 
ObjectAnimator anim = (ObjectAnim 
if (anim.mAutoCancel && hasSameTa 


anim.cancel(); 


} 


numAnims = handler.mPendingAnimations.size(); 
for (int i = numAnims -1; i => 0; i--) { 
if (handler .mPendingAnimations.get(i) ins 
ObjectAnimator anim = (ObjectAnim 
if (anim.mAutoCancel && hasSameTa 


anim.cancel(); 


上 面 的 代码 别 看 那么 长 ， 其 实 做 的 事情 很 简单 ， 首 先 会 判断 如 果 当 
前 动画 、 等 待 的 动画 〈Pending) 和 延迟 的 动画 〈Delay) 中 有 和 当前 动 





mA Ty, ASAE ARTA A oy Za AA te, Be PORES — log, 
再 接着 就 调用 了 父 类 的 super.start() 方 法 。 因 为 ObjectAnimator 继 承 了 
ValueAnimator， 上 所 以 接 下 来 我 们 看 一 下 ValueAnimator 的 Start 方 法 : 


private void start(boolean playBackwards) { 
if (Looper.myLooper() == null) { 
throw new AndroidRuntimeException("Animators may 


$ 


mPlayingBackwards = playBackwards; 


mCurrentIteration 0; 
mPlayingState = STOPPED; 
mStarted = true; 
mStartedDelay = false; 
mPaused = false; 
updateScaledDuration(); // in case the scale factor has c 
AnimationHandler animationHandler = getOrCreateAnimationH 
animationHandler .mPendingAnimations.add(this); 
if (mStartDelay == 0) { 
// This sets the initial value of the animation,p 
setCurrentPlayTime(0); 
mPlayingState = STOPPED; 
mRunning = true; 
notifyStartListeners(); 
} 


animationHandler.start(); 


可 以 看 出 属性 动画 需要 运行 在 有 Looper 的 线程 中 。 上 述 代 码 最 终 会 
调用 Animation-Handler 的 start 方 法 ， 这 个 AnimationHandler 并 不 是 
Handler， 它 是 一 个 Runnable。 看 一 下 它 的 代码 ， 通 过 代码 我 们 发 现 ， 很 
快 就 调 到 了 JNI 层 ， 不 过 JNI 层 最 终 还 是 要 调 回 来 的 。 它 的 run 方 法 会 被 
调用 ， 这 个 Runnable 涉 及 和 底层 的 交互 ， 我 们 就 忽略 这 部 分 ， 直 接 看 重 
点 : ValueAnimator 中 的 doAnimationFrame 方 法 ， 如 下 所 示 。 





mStartTime += (frameTime -mPauseTime) ; 


} 


// The frame time might be before the start time during the f 
// an animation. The "current time" must always be on or afte 
// time to avoid animating frames at negative time intervals. 
// is very rare and only happens when seeking backwards. 
final long currentTime = Math.max(frameTime,mStartTime) ; 


return animationFrame(currentTime) ; 





注意 到 上 述 代 码 末尾 调用 了 animationFrame 方 法 ， 而 animationFrame 
内 部 调用 了 animateValue， 下 面 看 animateValue 的 代码 ; 


void animateValue(float fraction) { 

fraction = mInterpolator.getInterpolation(fraction) ; 

mCurrentFraction = fraction; 

int numValues = mValues. length; 

for (int i = 0; i < numValues; ++i) { 
mValues[i].calculateValue(fraction); 

t 

if (mUpdateListeners != null) { 
int numListeners = mUpdateListeners.size(); 
for (int i = 0; i < numListeners; ++1) { 


mUpdateListeners.get(i).onAnimationUpdate 


上 述 代码 中 的 caleulateValue 广 法 就 是 计算 每 由 动画 所 对 应 的 属性 的 
值 ， 下 面 着 重 看 一 下 到 底 是 在 哪里 调用 属性 的 get 和 set 方 法 的 ， 毕 竟 这 
个 才 是 我 们 最 关心 的 。 


在 初始 化 的 时 候 ， 如 果 属 性 的 初始 值 没 有 提供 ， 则 get 方 法 将 会 被 
调用 ， 请 看 Property-ValuesHolder 的 setupValue 方 法 ， 可 以 发 现 get 方 法 是 
通过 反射 来 调用 的 ， 如 下 所 示 。 








当 动 画 的 下 一 帧 到 来 的 时 候 ，PropertyValuesHolder 中 的 
setAnimatedValue 方 法 会 将 新 的 属性 值 设 置 给 对 象 ， 调 用 其 set 方 法 。 从 
下 面 的 源码 可 以 看 出 ，set 方 法 也 是 通过 反射 来 调用 的 : 





7.4 使 用 动画 的 注意 事项 


通过 二 动画 可 以 实现 一 些 比 较 绚丽 的 效果 ， 但 是 在 使 用 过 程 中 ， 也 需 
主意 一 些 事情 ， 主 要 分 为 下 面 几 类 。 


Hy 





1. OOM 问 题 





这 个 问题 主要 出 现在 帧 动画 中 ， 当 图 片 数量 较 多 且 疼 片 较 大 时 就 极 
易 出 现 OOM， 这 个 在 实际 的 开发 中 要 尤其 注意 ， 尺 量 避 免 使 用 帧 动 


Hjo 
2. 内 存 泄 露 


在 属性 动画 中 有 一 类 无 限 循 环 的 动画 ， 这 类 动画 需要 在 Activity 退 
出 时 及 时 停止 ， 否 则 将 导致 Activity 无 法 释放 从 而 造成 内 存 泄 露 ， 通 过 
验证 后 发 现 View 动 画 并 不 存在 此 问题 。 

3. 兼容 性 问题 


动画 在 3.0 以 下 的 系统 上 有 兼容 性 问题 ， 在 茶 些 特殊 场景 可 能 无 法 
正常 工作 ， 因 此 要 做 好 适 配 工作 。 





4. View 动 画 的 问题 


View 动 画 是 对 View 的 影像 做 动画 ， 并 不 是 真正 地 改变 View 的 状 
态 ， 因 此 有 时 候 会 出 eel Te PE VIEN E IMR, BY 
setVisibility(View.GONE) 失 效 了 ， 这 个 时 候 只 要 调用 
view.clearAnimation() 清 除 View 动 画 即 可 解决 此 问题 。 


5. 不 要 使 用 px 


在 进行 动画 的 过 程 中 ， 要 尽量 使 用 dp， 使 用 px 会 导致 在 不 同 的 设备 
上 有 不 同 的 效果 。 








6. 动画 元 素 的 交互 


将 view 移 动 〈 平 移 ) 后 ， 在 Android 3.0 以 前 的 系统 上 ， 不 管 是 View 
动画 还 是 属性 动画 ， 新 位 置 均 无 法 触发 单 击 事件 ， 同 时 ， 老 位 置 仍然 可 
以 触发 单 击 事件 。 尽 管 View 已 经 在 视觉 上 不 存在 了 ， 将 View 移 回 原 位 
置 以 后 ， 原 位 置 的 单 击 事件 继续 生效 。 从 3.0 开 始 ， 属 性 动画 的 单 击 事 
件 触发 位 置 为 移动 后 的 位 置 ， 但 是 View 动 画 仍 然 在 原 位 置 。 





7. 便 件 加 速 


使 用 动画 的 过 程 中 ， 建 议 开 局 硬件 加速 ， 这 样 会 提高 动画 的 流畅 
te. 


oe ”理解 Window 和 和 
WindowManager 





Window 表 示 一 个 窗口 的 概念 ， 在 日 常 开发 中 直接 接触 Window 的 机 
会 并 不 多 ， 但 是 在 某 些 特殊 时 候 我 们 需要 在 果 面 上 显示 一 个 类 似 悬 浮 窗 
的 东西 ， 那 么 这 种 效果 就 需要 用 到 Window 来 实现 。Window 是 一 个 抽象 
类 ， 它 的 具体 实现 是 PhoneWindow。 创 建 一 个 Window 是 很 简单 的 事 ， 

只 需要 通过 WindowManager 即 可 完成 。WindowManager 是 外 界 访问 
Window 的 入 口 ，Window 的 具体 实现 位 于 WindowManagerService 中 ， 
WindowManager 和 Window-ManagerService 的 交互 是 一 个 IPC 过 程 。 
Android 中 所 有 的 视图 都 是 通过 Window 来 呈现 的 ， 不 管 是 Activity、 
Dialog 还 是 Toast， 它 们 的 视图 实际 上 都 是 附加 在 Window 上 的 ， 因 此 
Window 实 际 是 View 的 直接 管理 者 。 从 第 4 章 中 所 讲述 的 View 的 事件 分 
发 机 制 也 可 以 知道 ， 单 击 事件 由 Window 传 递 给 DecorView， 然 后 再 由 
DecorView 传 递 给 我 们 的 View， 就 连 Activity 的 设置 视图 的 方法 
setContentView 在 底层 也 是 通过 Window 来 完成 的 。 











8.1 Window! WindowManager 


为 了 分 析 Window 的 工作 机 制 ， 我 们 需要 先 了 解 如 何 使 用 
WindowManager 添 加 一 个 Window。 下 面 的 代码 演示 了 通过 
WindowManager 添 加 Window 的 过 程 ， 是 不 是 很 简单 呢 ? 





mFloatingButton = new Button(this); 
mFloatingButton.setText("button"); 
mLayoutParams = new WindowManager .LayoutParams( 
LayoutParams.WRAP_CONTENT, LayoutParams .WRAP_CONTE 
PixelFormat . TRANSPARENT ) ; 
mLayoutParams.flags = LayoutParams.FLAG_NOT_TOUCH_MODAL 
| LayoutParams.FLAG_NOT_FOCUSABLE 
| LayoutParams. FLAG_SHOW_WHEN_LOCKED 
mLayoutParams.gravity = Gravity.LEFT | Gravity.TOP; 
mLayoutParams.x = 100; 
mLayoutParams.y = 300; 


mwWindowManager .addView(mFloatingButton,mLayoutParams ) ; 


EA RES A WOR “Buttons WF BRA A (100, 300) 的 位 置 
o WindowManager. LayoutParams 中 的 fags 和 type 这 两 个 参数 比较 重 
， 下 面 对 其 进行 说 明 。 


烟 m 


Flags 参 数 表示 Window 的 属性 ， 它 有 很 多 选项 ， 通 过 这 些 选 项 可 以 
控制 Window 的 显示 特性 ， 这 里 主要 介绍 儿 个 比较 常用 的 选项 ， 剩 下 的 
请 碍 看 官方 文档 。 


FLAG_NOT_FOCUSABLE 





表示 Window 不 需要 获取 焦点 ， 也 不 需要 接收 各 种 输入 事件 ， 此 标 
记 会 同时 启用 FLAG_NOT_TOUCH MODAL， 最 终 事 件 会 直接 传递 给 
下 层 的 具有 焦点 的 Window。 








FLAG_NOT_TOUCH_MODAL 


在 此 模式 下 ， 系 统 会 将 当前 Window 区 域 以 外 的 单 击 事件 传递 给 底 
层 的 Window， 当 前 Window 区 域 以 内 的 单 击 事件 则 上 自己 处 理 。 这 个 标记 
很 重要 ， 一 般 来 说 都 需要 开局 此 标记 ， 人 否则 其 他 Window 将 无 法 收 到 单 
击 事件 。 


FLAG_SHOW_WHEN_LOCKED 
开启 此 模式 可 以 让 Window 显 示 在 锁 屏 的 界面 上 。 


Type 参数 表示 Window 的 类 型 ，Window 有 三 种 类 型 ， 分 别 是 应 用 
Window、 子 Window 和 系统 Window。 应 用 类 Window 对 应 着 一 个 
Activity。 子 Window 不 能 单独 存在 ， 它 需要 附属 在 特定 的 父 Window 之 
中 ， 比 如 常见 的 一 些 Dialog 束 是 一 个 子 Window。 系 统 Window 是 需要 声 
明 权 限 在 能 创建 的 window， 比 如 Toast 和 系统 状态 栏 这 些 都 是 系统 
Window。 


Window 是 分 层 的 ， 每 个 Window 都 有 对 应 的 z-ordered， 层 级 大 的 会 
履 盖 在 层级 小 的 window 的 上 面 ， 这 和 HTML 中 的 z-index 的 概念 是 完 
一 致 的。 在 三 类 Window 中 ， 应 用 Window 的 层级 范围 是 1~v99， 子 
Window 的 层级 范围 是 1000 一 1999， 系 统 Window 的 层级 范围 是 2000 一 
2999， 这 些 层级 范围 对 应 着 WindowManager.LayoutParams 的 type 参 数 。 


如 果 想 要 Window 位 于 所 有 Window 的 最 顶层 ， 那 么 采用 较 大 的 层级 即 
可 。 很 显然 系统 Window 的 层级 是 最 大 的 ， 而 且 系 统 层级 有 很 多 值 ， 

般 我 们 可 以 选用 TYPE_SYSTEM_OVERLAY 或 者 
TYPE_SYSTEM_ERROR， 如 果 采 用 TYPE_SYSTEM_ERROR， 只 需要 
为 type 参 数 指 定 这 个 层级 即 可 : mLayoutParams.type = 
LayoutParams.TYPE_SYSTEM_ ERROR; 同时 声明 权限 : <uses- 


permission 





android:name="android.permission.SYSTEM_ALERT_ WINDOW" />。 








为 系统 类 型 的 Window 是 需要 检查 权限 的 ， 如 果 不 在 AndroidManifest 中 
使 用 相应 的 权限 ， 那 么 创建 Window 的 时 候 就 会 报错 ， 错 误 如 下 所 示 。 


E/AndroidRuntime(8071): Caused by: android.view.WindowManager 


E/AndroidRuntime(8071): 
E/AndroidRuntime( 8071): 
E/AndroidRuntime( 8071): 
E/AndroidRuntime( 8071): 
E/AndroidRuntime( 8071): 
E/AndroidRuntime( 8071): 
E/AndroidRuntime(8071): 


W/ActivityManager( 514): 


WindowManager 所 提供 的 功 


at 
at 
at 
at 
at 
at 


au 
Ke 


android. 
android. 
android. 
android. 
android. 
com. ryg. 


. 14 more 


view.ViewRootImpl.setView( 
view.WindowManagerImpl.add 
view.WindowManagerImpl.add 
view.WindowManager Imp1$Com 
view.Window$LocalWindowMan 


chapter_8.TestActivity.onB 


Force finishing activity com.ryg.c 


很 简单 ， 


常用 的 只 有 三 个 方法 ， 即 添 





加 View、 更 新 View 和 删除 Visw， 这 三 个 方法 定义 在 ViewManager 中 ， 
而 WindowManager 继 承 了 ViewManager。 


public interface ViewManager 


public void addView(View view, ViewGroup.LayoutParams par 


public void updateViewLayout(View view, ViewGroup.LayoutP 


public void removeView(View view); 





WIRE Kit, WindowManageris HR AXZ Remo, 1E 
是 这 三 个 功能 已 经 足够 我 们 使 用 了 。 它 可 以 创建 一 个 Window 并 同 其 添 
加 View， 还 可 以 更 新 Window 中 的 View， 男 外 如 果 想 要 删除 一 个 
Window， 那 么 只 需要 删除 它 里 面 的 View 即 可 。 由 此 来 看 ， 
WindowManager 操 作 Window 的 过 程 更 像 是 在 操作 Window 中 的 View。 我 
们 时 常见 到 那 种 可 以 拖 动 的 Window 效 果 ， 其 实 是 很 好 实现 的 ， 只 需要 
根据 手指 的 位 置 来 设 定 LayoutParams 中 的 x 和 y 的 值 即 可 改变 Window 的 
人 位置。 首先 给 View 设 置 onTouchListener: 
mFloatingButton.setOnTouchListener(this)。 然 后 在 onTouch 方 法 中 不 断 更 
新 View 的 位 置 即 可 : 





public boolean onTouch(View v,MotionEvent event) { 

int rawX = (int) event.getRawXx(); 

int rawY = (int) event.getRawyY(); 

switch (event.getAction()) { 

case MotionEvent.ACTION_MOVE: { 
mLayoutParams.x = rawX; 
mLayoutParams.y = rawyY; 
mWindowManager .updateViewLayout (mFloatingButton,m 
break; 

i 

default: 


break; 


8.2 Window 的 内 部 机 制 


Window 是 一 个 抽象 的 概念 ， 每 一 个 Window 都 对 应 着 一 个 View 和 一 
个 ViewRootImpl，Window 和 View 通 过 ViewRootImpl 来 建立 联系 ， 因 此 
Window 并 不 是 实际 存在 的 ， 它 是 以 View 的 形式 存在 。 这 点 从 
WindowManager 的 定义 也 可 以 看 出 ， 它 提供 的 三 个 接口 方法 addView、 
updateViewLayout 以 及 removeView 都 是 针对 View 的 ， 这 说 明 View 才 是 
Window 存 在 的 实体 。 在 实际 使 用 中 无 法 直接 访问 Window， 对 Window 
的 访问 必须 通过 WindowManager。 为 了 分 析 Window 的 内 部 机 制 ， 这 里 
从 Window 的 添加 、 删 除 以 及 更 新 说 起 。 








8.2.1 Window 的 添加 过 程 


Window 的 添加 过 程 需 要 通过 WindowManager 的 addView 来 实现 ， 
WindowManager 是 一 个 接口 ， 它 的 真正 实现 是 WindowManagerImpl 类 。 
在 WindowManagerImpl 中 Window 的 三 大 操作 的 实现 如 下 : 


@Override 

public void addView(View view, ViewGroup.LayoutParams params) 
mGlobal.addView( view, params, mDisplay, mParentWindow) ; 

Í 

@Override 

public void updateViewLayout(View view, ViewGroup.LayoutParams 


mGlobal.updateViewLayout (view, params); 


@Override 
public void removeView(View view) { 


mGlobal.removeView(view, false); 


可 以 发 现 ，WindowManagerImpl 并 没有 直接 实现 Window 的 三 大 操 
作 ， 而 是 全 部 交 给 了 WindowManagerGlobal 来 处 理 ， 
WindowManagerGlobal 以 工厂 的 形式 癌 外 提供 自己 的 实例 ， 在 
WindowManagerGlobal 中 有 如 下 一 段 代 码 : private final 
WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance(). 
WindowManagerImpl 这 种 工作 模式 是 典型 的 桥接 模式 ， 将 所 有 的 操作 全 
部 委托 给 WindowManagerGlobal 来 实现 。WindowManager-Global 的 
addView 方 法 主要 分 为 如 下 几 步 。 





1. 检查 参数 是 否 合法 ， 如 果 是 子 Window 那 么 还 需要 调整 一 些 布局 
参数 


if (view == null) { 

throw new IllegalArgumentException("view must not be null 
} 
if (display == null) { 

throw new IllegalArgumentException("display must not be n 
} 
if (!(params instanceof WindowManager.LayoutParams)) { 

throw new IllegalArgumentException("Params must be Window 
} 
final WindowManager.LayoutParams wparams = (WindowManager .Lay 


if (parentWindow != null) { 


parentWindow.adjustLayoutParamsForSubWindow(wparams ) ; 


2. 创建 ViewRootImpl 并 将 View 添 加 到 列表 中 
在 WindowManagerGlobal 内 部 有 如 下 几 个 列表 比较 重要 : 


private final ArrayList<View> mViews = new ArrayList<View>(); 
private final ArrayList<ViewRootImpl> mRoots = new Array 
<ViewRootImp1l>(); 
private final ArrayList<WindowManager.LayoutParams> mPar 
new ArrayList<WindowManager.LayoutParams>(); 


private final ArraySet<View> mDyingViews = new ArraySet<View> 


在 上 面 的 声明 中 ，mViews 存 储 的 是 所 有 Window 所 对 应 的 View， 
mRoots 存 储 的 是 所 有 Window 所 对 应 的 ViewRootImpl1，mParams 存 储 的 
是 所 有 Window 所 对 应 的 布局 参数 ， 而 mDyingViews 则 存储 了 那些 正在 
被 删除 的 View 对 象 ， 或 者 说 是 那些 已 经 调用 removeView 方 法 但 是 删除 
操作 还 未 完成 的 window 对 象 。 在 addView 中 通过 如 下 方式 将 Window 的 
一 系列 对 象 添加 到 列表 中 : 


root = new ViewRootImpl(view.getContext(),display); 
view.setLayoutParams(wparams ) ; 

mViews.add(view); 

mRoots.add(root); 


mParams.add(wparams ) ; 


3. 通过 ViewRootImpl 来 更 新 界面 并 完成 Window 的 添加 过 程 


步骤 由 ViewRootImpl 的 setView 方 法 来 完成 ， 从 第 4 章 可 以 知 
ee 会 制 过 程 是 由 ViewRootImpl] 来 完成 的 ， 这 里 当然 也 不 例外 ， 
在 setView 内 部 会 通过 requestLayout 来 完成 异步 刷新 请 求 。 在 下 面 的 代码 
中 ，scheduleTraversals 实 际 是 View 绘 制 的 入 口 : 





public void requestLayout() { 
if (!mHandlingLayoutInLayoutRequest) { 
checkThread(); 
mLayoutRequested = true; 


scheduleTraversals(); 


接着 会 通过 WindowSession 最 终 来 完成 Window 的 添加 过 程 。 在 下 面 
的 代码 中 ，mWindowSession 的 类 型 是 [WindowSession， 它 是 一 个 Binder 
对 象 ， 真 正 的 实现 类 是 Session， 也 就 是 Window 的 添加 过 程 是 一 次 IPC 调 
H- 





try { 
mOrigwindowType = mWindowAttributes.type; 
mAttachInfo.mRecomputeGlobalAttributes = true; 
collectViewAttributes(); 
res = mWindowSession.addToDisplay(mWindow, mSeq, mWwindowAtt 
getHostVisibility(),mDisplay.getDisplayId 
mAttachInfo.mContentInsets, mInputChannel ) 
} catch (RemoteException e) { 
mAdded = false; 


mView = null; 


mAttachInfo.mRootView = null; 
mInputChannel = null; 
mFallbackEventHandler.setView(null); 
unscheduleTraversals(); 
setAccessibilityFocus(null, null); 


throw new RuntimeException("Adding window failed",e); 


在 Session 内 部 会 通过 WindowManagerService 来 实现 Window 的 添 
加 ， 代 码 如 下 所 示 。 


public int addToDisplay(IWindow window, int seq,WindowManager. 
attrs, 
int viewVisibility,int displayId,Rect outContentI 
InputChannel outInputChannel) { 
return mService.addwWindow(this, window, seq, attrs, viewVisib 


outContentInsets, outInputChannel); 
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理 了 ， 在 Window-ManagerService 内 部 会 为 每 一 个 应 用 保留 一 个 单独 的 
Session 。 Fale NODOSA Wo ManagerService 内 部 是 怎么 添加 的 ， 本 
章 不 对 其 进行 进一步 的 分 析 ， 这 是 因为 到 此 为 止 我 们 对 Window 的 添加 

一 流程 已 经 清楚 了 ， 而 在 WindowManagerService 内 部 主要 是 代码 细 

节 ， 深 入 进去 没有 太 大 的 意义 ， 读 者 可 以 自行 阅读 源码 或 者 参考 相关 的 
源码 分 析 书 籍 ， 本 书 对 源码 的 分 析 侧 重 的 是 整体 流程 ， 会 尽量 避免 出 现 
深入 代码 逻辑 无 法 自拔 的 情形 。 








8.2.2 Window 的 删除 过 程 


Window 的 删除 过 程 和 添加 过 程 一 样 ， 都 是 先 通 过 
WindowManagerImpl 后 ， 再 进一步 通过 WindowManagerGlobal 来 实现 
的 。 下 面 是 WindowManagerGlobal 的 removeView 的 实现 : 


public void removeView(View view,boolean immediate) { 
if (view == null) { 
throw new IllegalArgumentException("view must not 
t 
synchronized (mLock) { 
int index = findViewLocked(view, true); 
View curView = mRoots.get(index).getView(); 
removeViewLocked(index, immediate); 
if (curView == view) { 
return; 
j; 
throw new IllegalStateException("Calling with vie 


+ " but the ViewAncestor is attac 


removeView 的 逻辑 很 清晰 ， 首 先 通 过 findViewLocked 来 查找 竺 删除 
的 View 的 索引 ， 这 个 查找 过 程 束 是 建立 的 数组 授 历 ， 然 后 再 调用 
removeViewLocked 来 做 进一步 的 删除 ， 如 下 所 示 。 


private void removeViewLocked(int index,boolean immediate) { 


ViewRootImpl root = mRoots.get(index); 

View view = root.getView(); 

if (view != null) { 
InputMethodManager imm = InputMethodManager.getIn 
if (imm != null) { 


imm.windowDismissed(mViews.get(index).get’ 


Í 
boolean deferred = root.die(immediate); 
if (view != null) { 
view.assignParent(null); 
if (deferred) { 


mDyingViews.add(view) ; 


removeViewLocked 是 通过 ViewRootImpl 来 完成 删除 操作 的 。 在 
WindowManager 中 提供 了 两 种 删除 接口 removeView 和 
removeViewImmediate， 它 们 分 别 表示 异步 删除 和 同步 删除 ， 其 中 
removeViewImmediate 使 用 起 来 需要 特别 注意 ， 一 般 来 说 不 需要 使 用 此 
方法 来 删除 Window 以 免 发 生意 外 的 错误 。 这 里 主要 说 异步 删除 的 情 
况 ， 有 具体 的 删除 操作 由 ViewRoot-Impl 的 die 方 法 来 完成 。 在 异步 删除 的 
情况 下 ，die 方 法 只 是 发 送 了 一 个 请 求 删 除 的 消息 后 就 立刻 返回 了 ， 这 
个 时 候 View 并 没有 完成 删除 操作 ， 上 所 以 最 后 会 将 其 添加 到 mDyingViews 
中 ，mDyingViews 表 示 待 删除 的 View 列 表 。ViewRootImpl 的 die 方 法 如 
RATAN» 











boolean die(boolean immediate) { 
// Make sure we do execute immediately if we are in the m 
// done by dispatchDetachedFromwindow will cause havoc on 
if (immediate && !mIsInTraversal) { 
doDie(); 
return false; 
J 
if (!mIsDrawing) { 
destroyHardwareRenderer(); 
} else { 
Log.e(TAG, "Attempting to destroy the window while 
" window=" + this + ",title=" + m 
getTitle()); 
i 
mHandler .sendEmptyMessage(MSG_DIE); 


return true; 


在 die 方 法 内 部 只 是 做 了 人 简单 的 判断 ， 如 果 是 异步 删除 ， 那 么 就 发 
送 一 个 MSG_DIE 的 消息 ，ViewRootImpl 中 的 Handler 会 处 理 此 消息 并 调 
用 doDie 方 法 ， 如 果 是 同步 删除 《立即 删除 ) ， 那 么 驶 不 发 消息 直接 调 
用 doDie 方 法 ， 这 就 是 这 两 种 删除 方式 的 区 别 。 在 doDie 内 部 会 调用 
dispatchDetachedFromWindow 方 法 ， 真 正 删除 View 的 逻辑 在 
dispatchDetachedFromWindow 方 法 的 内 部 实现 。 
dispatchDetachedFromWindow 方 法 主要 做 四 件 事 : 





(1) 垃圾 回收 相关 的 工作 ， 比 如 清除 数据 和 消息 、 移 除 回 调 。 


(2) 通过 Session 的 remove 方 法 删除 Window: 
mWindowSession.remove(mWindow)， 这 同样 是 一 个 IPC 过 程 ， 最 终 会 调 
用 WindowManagerService 的 removeWindow 方 法 。 





(3) 调用 View 的 dispatchDetachedFromWindow 方 法 ， 在 内 部 会 调 
用 View 的 onDetached-FromWindow() 以 及 
onDetachedFromWindowlInternal()。 对 于 onDetachedFromWindow() 大 家 
一 定 不 卫生 ， 当 View 从 Window 中 移 除 时 ， 这 个 方法 束 会 被 调用 ， 可 以 
在 这 个 方法 内 部 做 一 些 资源 回收 的 工作 ， 比 如 终止 动画 、 停 止 线 程 等 。 





(4) 调用 WindowManagerGlobal 的 doRemoveView 方 法 刷新 数据 ， 
包括 mRoots、mpParams 以 及 mDyingViews， 需 要 将 当前 Window 所 关联 的 
这 三 类 对 象 从 列表 中 删除 。 


8.2.3 “Window 的 更 新 过 程 


到 这 里 ，Window 的 删除 过 程 已 经 分 析 完 毕 了 ， 下 面 分 析 Window 的 
更 新 过 程 ， 还 是 要 看 WindowManagerGlobal 的 updateViewLayout 方 法 ， 
如 下 所 示 。 


public void updateViewLayout(View view, ViewGroup.LayoutParams 
if (view == null) { 
throw new IllegalArgumentException("view must not 
} 
if (!(params instanceof WindowManager .LayoutParams)) { 


throw new IllegalArgumentException("Params must b 


final WindowManager.LayoutParams wparams = (WindowManager 

view.setLayoutParams(wparams ) ; 

synchronized (mLock) { 
int index = findViewLocked(view, true); 
ViewRootImpl root = mRoots.get(index); 
mParams.remove(index); 
mParams.add(index,wparams) ; 


root.setLayoutParams(wparams, false); 


updateViewLayout 方 法 做 的 事情 就 比较 简单 了 ， 首 先 它 需要 更 新 
View 的 LayoutParams 并 蔡 换 掉 老 的 LayoutParams， 接 着 再 更 新 
ViewRootImpl 中 的 LayoutParams， 这 一 步 是 通过 ViewRootImpl 的 
setLayoutParams 方 法 来 实现 的 。 在 ViewRootImpl 中 会 通过 
ScheduleTraversals 方 法 来 对 View 重 新 布局 ， 包 括 测量 、 布 局 、 重 绘 这 三 
个 过 程 。 除 了 View 本 身 的 重 绘 以 外 ， Who TA 通过 
WindowSession 来 更 新 Window 的 视图 ， 这 个 过 程 最 终 是 由 
WindowManagerService 的 relayoutWindow() 来 具体 实现 的 ， 它 同样 是 一 
个 IPC 过 程 。 








8.3 Window} il Æ iF 


通过 上 面 的 分 析 可 以 看 出 ，View 是 Android 中 的 视图 的 呈现 方式 ， 
但 是 View 不 能 单独 存在 ， 它 必须 附着 在 Window 这 个 抽象 的 概念 上 面 ， 
因此 有 视图 的 地 方 就 有 Window。 哪 些 地 方 有 视图 呢 ? 这 个 读者 都 比较 
清楚 ，Android 中 可 以 提供 视图 的 地 方 有 Activity、Dialog、Toast， 除 此 
之 外 ， 还 有 一 些 依托 Window 而 实现 的 视图 ， 比 如 PopUpWindow、 沫 
单 ， 它 们 也 是 视图 ， 有 视图 的 地 方 束 有 Window， 因 此 Activity、 
Dialog、Toast 等 视图 都 对 应 着 一 个 Window。 本 节 将 分 析 这 些 视 图 元 素 
中 的 Window 的 创建 过 程 ， 通 过 本 节 可 以 使 读者 进一步 加 深 对 Window 的 
理解 。 





8.3.1 _ Activity 的 Window 创 建 过 程 


要 分 析 Activity 中 的 Window 的 创建 过 程 就 必须 了 解 Activity 的 启动 过 
程 ， 详 细 的 过 程 会 在 第 9 章 进 行 介绍 ， 这 里 先 大 概 了 解 即 可 。Activity 的 
启动 过 程 很 复杂 ， 最 终 会 由 ActivityThread 中 的 performLaunchActivity() 
来 完成 整个 启动 过 程 ， 在 这 个 方法 内 部 会 通过 类 加 载 器 创建 Activity 的 
实例 对 象 ， 并 调用 其 attach 方 法 为 其 关联 运行 过 程 中 所 依赖 的 一 系列 上 
下 文 环境 变量 ， 代 码 如 下 所 示 。 








java.lang.ClassLoader cl = r.packageInfo.getClassLoader(); 
activity = mInstrumentation.newActivity( 


cl,component.getClassName(),r.intent); 


if (activity != null) { 
Context appContext = createBaseContextForActivity(r,activ 
CharSequence title = r.activityInfo.loadLabel(appContext. 
Configuration config = new Configuration(mCompatConfigura 
if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity " 
+ r.activityInfo.name + " with config " + 
activity.attach(appContext, this, getInstrumentation(),r.to 
r.ident,app,r.intent,r.activityInfo, title 
r.embeddedID, r.LastNonConfigurationInstan 


r.voiceInteractor); 


在 Activity 的 attach 方 法 里 ， 系 统 会 创建 Activity 所 属 的 Window 对 象 
并 为 其 设置 回调 接口 ，Window 对 象 的 创建 是 通过 PolicyManager 的 
makeNewWindow 方 法 实现 的 。 由 于 Activity 实 现 了 Window 的 Callback 接 
口 ， 因 此 当 Window 接 收 到 外 界 的 状态 改变 时 融会 回调 Activity 的 方法 。 
Callback 接 口中 的 方法 很 多 ， 但 是 有 几 个 却 是 我 们 都 非常 熟悉 的 ， 比 如 
onAttachedIoWindow、onDetachedFromWindow、dispatchIouchEvent， 
等 等 ， 代 码 如 下 所 示 。 





mwindow = PolicyManager .makeNewWindow( this); 
mwWindow.setCallback(this); 
mWindow.setOnWindowDismissedCallback(this); 

mwindow. getLayoutInflater().setPrivateFactory(this); 

if (info.softInputMode != WindowManager.LayoutParams.SOFT_INP 


mwWindow. setSoftInputMode(info.softInputMode) ; 


t 
if (info.ui0ptions != 0) { 


mWindow.setUiOptions(info.uiOptions); 


从 上 面 的 分 析 可 以 看 出 ，Activity 的 Window 是 通过 PolicyManager 的 
一 个 工厂 方法 来 创建 的 ， 但 是 从 PolicyManager 的 类 名 可 以 看 出 ， 它 不 是 
一 个 普通 的 类 ， 它 是 一 个 策略 类 。PolicyManager 中 实现 的 几 个 工厂 方法 
全 部 在 策略 接口 IPolicy 中 声明 了 ，IPolicy 的 定义 如 下 : 





public interface IPolicy { 
public Window makeNewWindow(Context context); 
public LayoutInflater makeNewLayoutiInflater(Context cont 
public WindowManagerPolicy makeNewWindowManager (); 
public FallbackEventHandler makeNewFallbackEventHandler ( 


context); 


在 实际 的 调用 中 ，PolicyManager 的 真正 实现 是 Policy 类 ，Policy 类 
中 的 makeNewWindow 方 法 的 实现 如 下 ， 由 此 可 以 发 现 ，Window 的 具体 
实现 的 确 是 PhoneWindow。 


public Window makeNewWindow(Context context) { 


return new PhoneWindow(context); 
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源码 中 的 调用 关系 来 得 出 ， 这 里 猜测 可 能 是 由 编译 环节 动态 控制 的 。 到 


这 里 Window 已 经 创建 完成 了 ， 下 面 分 析 Activity 的 视图 是 怎么 附属 在 
Window 上 的 。 由 于 Activity 的 视图 由 setContentView 方 法 提供 ， 我 们 只 需 
要 看 setContentView 方 法 的 实现 即 可 。 


public void setContentView(int layoutResID) { 
getWindow().setContentView(layoutResID); 


initWindowDecorActionBar(); 


从 Activity 的 setContentView 的 实现 可 以 看 出 ，Activity 将 具体 实现 交 
给 了 Window 人 处理 ， 而 Window 的 具体 实现 是 PhoneWindow， 所 以 只 需要 
看 PhoneWindow 的 相关 逻辑 即 可 。PhoneWindow 的 setContentView 方 法 
大 致 遵循 如 下 几 个 步 又 。 


1. 如 果 没 有 DecorView， 那 么 就 创建 它 





DecorView 是 一 个 FrameLayout， 在 第 4 章 已 经 做 了 初步 的 介绍 ， 这 
里 再 简单 说 一 下 。DecorView 是 Activity 中 的 顶级 View， 一 般 来 说 它 的 内 
部 包含 标题 栏 和 内 部 栏 ， 但 是 这 个 会 随 着 主题 的 变换 而 发 后 改变 。 不 管 
怎么 样 ， 内 容 栏 是 一 定 要 存在 的 ， 并 且 内 容 来 具体 固定 的 d， 那 就 
是 “content”， 它 的 完整 id 是 android.R.id.content。DecorView 的 创建 过 程 
由 installDecor 方 法 来 完成 ， 在 方法 内 部 会 通过 generateDecor 方 法 来 直接 
创建 DecorView， 这 个 时 候 DecorView 还 只 是 一 个 空白 的 FrameLayout: 








protected DecorView generateDecor() { 


return new DecorView(getContext(),-1); 


为 了 初始 化 DecorView 的 结构 ，PhoneWindow 还 需要 通过 
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文件 和 系统 版 本 以 及 主题 有 关 ， 这 个 过 程 如 下 所 示 。 


View in = mLayoutInflater.inflate(layoutResource, null); 
decor .addView(in, new ViewGroup.LayoutParams (MATCH_PARENT, MATC 
mContentRoot = (ViewGroup) in; 


ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_ 


其 中 ID ANDROID CONTENT 的 定义 如 下 ， 这 个 id 所 对 应 的 


ViewGroup st %mContentParent: 


public static final int ID_ANDROID_CONTENT = com.android.inte 
2. 将 View 添 加 到 DecorView 的 mContentParent 中 


文 个 过 程 束 比较 简单 了 ， 由 于 在 步 又 1 中 己 经 创建 并 初始 化 了 
DecorView， 因 此 这 一 步 直接 将 Activity 的 视图 添加 到 DecorView 的 
mContentParent 中 即 可 : 
mLayoutInflater.inflate(layoutResID,mContentParenD。 到 此 为 止 ，Activity 
的 布局 文件 已 经 添加 到 DecorView 里 面 了 ， 由 此 可 以 EE Oy 的 
setContentView 这 个 方法 的 来 历 了 。 不 知道 读者 是 否 曾经 怀疑 过 : Att 
么 不 叫 setView 呢 ?” 它 明明 是 给 Activity 设 置 视图 的 啊 ! 从 这 里 来 看 ， 它 
的 确 不 适合 叫 setView， 因 为 Activity 的 布局 文件 只 是 被 添加 到 DecorView 
的 mContentParent 中 ， 因 此 叫 setContentView 更 加 准确 。 





3. 回调 Activity 的 onContentChanged 方 法 通知 Activity 视 图 已 经 发 
AE AAR 


这 个 过 程 就 更 简单 了 ， 由 于 Activity 实 现 了 Window 的 Callback 接 


口 ， 这 里 表示 Activity 的 布局 文件 已 经 被 添加 到 DecorView 的 
mContentParent 中 了 ， 于 是 需要 通知 Activity， 使 其 可 以 做 相应 的 处 理 。 
Activity 的 onContentChanged 方 法 是 个 空 实现 ， 我 们 可 以 在 子 Activity 中 
处 理 这 个 回调 。 这 个 过 程 的 代码 如 下 所 示 。 








final Callback cb = getcallback( ); 

if (cb != null && !isDestroyed()) { 
cb.onContentChanged(); 

J 


经 过 了 上 面 的 三 个 步骤 ， 到 这 里 为 止 DecorView 已 经 被 创建 并 初始 
化 完毕 ，Activity 的 布局 文件 也 已 经 成 功 添 加 到 了 DecorView 的 
mContentParent 中 ， 但 是 这 个 时 候 DecorView 还 没有 被 WindowManager 正 
式 添 加 到 Window 中 。 这 里 需要 正确 理解 Window 的 概念 ，Window 更 多 
表示 的 是 一 种 抽象 的 功能 集合 ， 虽 然 说 早 在 Activity 的 attach 方 法 中 
Window 就 已 经 被 创建 了 ， 但 是 这 个 时 候 由 于 DecorView 并 没有 被 
WindowManager 识 别 ， 所 以 这 个 时 候 的 Window 无 法 提供 具体 功能 ， 
为 它 还 无 法 接收 外 界 的 输入 信息 。 在 ActivityThread 的 
handleResumeActivity 方 法 中 ， 首 先 会 调用 Activity 的 onResume 方 法 ， 接 
着 会 调用 Activity 的 makeVisible()， 正 是 在 makeVisible 方 法 中 ， 
DecorView 真 正 地 完成 了 添加 和 显示 这 两 个 过 程 ， 到 这 里 Activity 的 视图 
才能 被 用 户 看 到 ， 如 下 所 示 。 








void makeVisible() { 
if (!mWindowAdded) { 
ViewManager wm = getWindowManager(); 
wm.addView(mDecor, getWindow( ).getAttributes()); 


mWindowAdded = true; 


t 
mDecor.setVisibility(View.VISIBLE); 


Ww 


到 这 里 ，Activity 中 的 Window 的 创建 过 程 已 经 分 析 完 了 ， 读 者 对 整 
个 过 程 是 不 是 有 了 更 进一步 的 理解 了 呢 ? 








8.3.2 Dialog 的 Window 创 建 过 程 


Dialog 的 Window 的 创建 过 程 和 Activity 类 似 ， 有 如 下 几 个 步 又。 
1. 创建 Window 


Dialog 中 Window 的 创建 同样 是 通过 PolicyManager 的 
makeNewWindow 方 法 来 完成 的 ， 从 8.3.1 市 中 可 以 知道 ， 创 建 后 的 对 象 
KPR Eat We 这 个 过 程 和 Activity 的 Window 的 创建 过 程 是 
一 致 的 ， 这 里 就 不 再 详细 说 明了 。 


Dialog(Context context,int theme,boolean createContextThemewr 


mWindowManager = (WindowManager )context.getSystemService( 
Window w = PolicyManager .makeNewWindow(mContext) ; 

mWindow = w; 

w.setCallback(this); 
w.setOnWindowDismissedCallback(this); 

w.setWindowManager (mWindowManager, null, null); 


w.setGravity(Gravity.CENTER) ; 


mListenersHandler = new ListenersHandler(this); 


2. 初始 化 DecorView 并 将 Dialog 的 视图 添加 到 DecorView 中 


过 程 也 和 Activity 的 类 似 ， 都 是 通过 Window 去 添加 指定 的 布局 
Ti ; 


public void setContentView(int layoutResID) { 


mWindow.setContentView(layoutResID); 


3. 4% DecorView JI 2!) Window F J} tz AN 


在 Dialog 的 show 方 法 中 ， 会 通过 WindowManager 将 DecorView 添 加 
到 Window 中 ， 如 下 所 示 。 


mwindowManager .addView(mDecor,1); 


mShowing = true; 


从 上 面 三 个 步骤 可 以 发 现 ，Dialog 的 Window 创 建 和 Activity 的 
Window 创 建 过 程 很 类 似 ， 二 者 几乎 没有 什么 区 别 。 当 Dialog 被 关闭 时 ， 
它 会 通过 WindowManager 来 移 除 DecorView: 


mWindowManager.removeViewImmediate(mDecor)。 


普通 的 Dialog 有 一 个 特殊 之 处 ， 那 就 是 必须 采用 Activity 的 Context， 
如 果 采 用 Application 的 Context， 那 么 就 会 报错 。 


Dialog dialog = new Dialog(this.getApplicationContext()); 


TextView textView = new TextView(this); 


textView.setText("this is toast!"); 


dialog.setContentView(textView) ; 


dialog.show(); 


上 述 代码 运行 时 会 报错 ， 
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普 误 信息 如 下 所 示 。 


Caused by: android.view.WindowManager 
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上 面 的 错误 信息 很 明确 ， 是 没有 应 用 token 所 导致 的 ， 而 应 用 token 
一 般 只 有 Activity 拥 有 ， 所 以 这 里 只 需要 用 Activity 作 为 Context 来 显示 对 
话 框 即 可 。 男 外 ， 系 统 Window 比 较 特殊 ， 它 可 以 不 需要 token， 因 此 在 
上 面 的 例子 中 ， 只 需要 指定 对 话 框 的 Window 为 系统 类 型 就 可 以 正常 弹 
出 对 话 框 。 在 本 章 一 开始 讲 到 ，WindowManager.LayoutParams 中 的 type 
表示 Window 的 类 型 ， 而 系统 Window 的 层级 范围 是 2000~~2999， 这 些 层 
级 范围 就 对 应 着 type 参 数 。 系 统 Window 的 层级 有 很 多 值 ， 对 于 本 例 来 
说 ， 可 以 选用 TYPE_SYSTEM_OVERLAY 来 指定 对 话 框 的 Window 类 型 





为 系统 Window， 如 下 所 示 。 


dialog.getWindow().setType(LayoutParams.TYPE_SYSTEM_ERROR) 


SR a ales J Æ AndroidManifest L4 F HA AC BR M if Ay DA H AA st 
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<uses-permission android:name="android.permission.SYSTEM_ALER 


8.3.3 Toast) Window] 2 it #2 


Toast Dialog E], CAN TEN ERT 78. H FToastth 23k T 
Window 来 实现 的 ， 但 是 由 于 Toast 具 有 定时 取消 这 一 功能 ， 所 以 系统 采 
用 了 Handler。 在 Toast 的 内 部 有 两 类 IPC 过 程 ， 第 一 类 是 Toast 访 问 
NotificationManagerService， 第 二 类 是 Notification-ManagerService 回 调 
Toast 里 的 TN 接 口 。 关 于 IPC 的 一 些 知识 ， 请 读者 参考 第 2 章 的 相关 内 
容 。 为 了 便于 描述 ， 下 面 将 NotificationManagerService 简 称 为 NMS 。 























Toast 属 于 系统 Window， 它 内 部 的 视图 由 两 种 方式 指定 ， 一 种 是 系 
统 默 认 的 样式 ， 另 一 种 是 通过 setView 方 法 来 指定 一 个 自 定义 View， 不 
管 如 何 ， 它 们 都 对 应 Toast 的 一 个 View 类 型 的 内 部 成 员 mNextView。 
Toast 提 供 了 show 和 cancel 分 别 用 于 显示 和 隐藏 Toast， 它 们 的 内 部 是 一 个 
IPC 过 程 ，show 方 法 和 cancel 方 法 的 实现 如 下 : 








public void show() { 
if (mNextView == null) { 
throw new RuntimeException("setView must have bee 


} 


INotificationManager service = getService(); 


String pkg = mContext.getOpPackageName()/; 
TN tn = mTN; 
tn.mNextView = mNextView; 
try { 
service.enqueueToast (pkg, tn,mDuration); 
} catch (RemoteException e) { 


// Empty 


} 


public void cancel() { 
mTN.hide(); 
try { 
getService().cancelToast(mContext .getPackageName ( 
} catch (RemoteException e) { 


// Empty 


从 上 面 的 代码 可 以 看 到 ， 显 示 和 隐藏 Toast 都 需要 通过 NMS 来 实 
现 ， 由 于 NMS 运 行 在 系统 的 进程 中 ， 所 以 只 能 通过 远程 调用 的 方式 来 显 
示 和 隐藏 Toast。 需 要 注意 的 是 TN 这 个 类 ， 它 是 一 个 Binder 类 ， 在 Toast 
和 NMS 进 行 IPC 的 过 程 中 ， 当 NMS 处 理 Toast 的 显示 或 隐藏 请 求 时 会 跨 进 
程 回调 TN 中 的 方法 ， 这 个 时 候 由 于 TN 运行 在 Binder 线 程 池 中 ， 所 以 需 
要 通过 Handler 将 其 切换 到 当前 线程 中 。 这 里 的 当前 线程 是 指 发 送 Toast 
请 求 所 在 的 线程 。 注 意 ， 由 于 这 里 使 用 了 Handler， 所 以 这 意味 着 Toast 
无 法 在 没有 Looper 的 线程 中 弹出 ， 这 是 因为 Handler 需 要 使 用 Looper 才 能 
完成 切换 线程 的 功能 ， 关 于 Handler 和 Looper 的 具体 介绍 请 参看 第 10 章 。 











首先 看 Toast 的 显示 过 程 ， 它 调用 了 NMS 中 的 enqueueToast 方 法 ， 如 
下 所 示 。 


INotificationManager service = getService(); 
String pkg = mContext.getOpPackageName()/; 
TN tn = mTN; 
tn.mNextView = mNextView; 
try { 

service.enqueueToast(pkg, tn,mDuration); 
} catch (RemoteException e) { 


// Empty 


NMS 的 enqueueToast 方 法 的 第 一 个 参数 表示 当前 应 用 的 包 名 ， 第 二 
个 参数 mm 表示 远程 回调 ， 第 三 个 参数 表示 Toast 的 时 长 。enqueueToast 首 
先 将 Toast 请 求 封 装 为 ToastRecord 对 象 并 将 其 添加 到 一 个 名 为 
mToastQueue 的 队列 中 。mToastQueue 其 实 是 一 个 ArrayList。 对 于 非 系统 
应 用 来 说 ，mToastQueue 中 最 多 能 同时 存在 50 个 ToastRecord， 这 样 做 是 
为 了 防止 DOS (Denial of Service) 。 如 果 不 这 么 做 ， 试 想 一 下 ， 如 果 我 
们 通过 大 量 的 循环 去 连续 弹出 Toast， 这 将 会 导致 其 他 应 用 没有 机 会 弹 
出 Toast， 那 么 对 于 其 他 应 用 的 Toast 请 求 ， 系 统 的 行为 就 是 拒绝 服务 ， 
这 就 是 拒绝 服务 攻击 的 售 义 ， 这 种 手段 常用 于 网 络 攻击 中 。 





// Limit the number of toasts that any given package except t 
// package can enqueue. Prevents DOS attacks and deals with 1 
if (!isSystemToast) { 

int count = 0; 


final int N = mToastQueue.size(); 





正常 情况 下 ， 一 个 应 用 不 可 能 达到 上 限 ， 当 ToastRecord 被 添加 到 
mToastQueue 中 后 ，NMS 就 会 通过 showNextToastLocked 方 法 来 显示 当前 
的 Toast。 下 面 的 代码 很 好 理解 ， 需 要 注意 的 是 ，Toast 的 显示 是 由 
ToastRecord 的 callback 来 完成 的 ， 这 个 callback 实 际 上 就 是 Toast 中 的 TN 
对 象 的 远程 Binder， 通 过 callback 来 访问 TN 中 的 方法 是 需要 路 进程 来 完 
成 的 ， 最 终 被 调用 的 TN 中 的 方法 会 运行 在 发 起 Toast 请 求 的 应 用 的 
Binder 线 程 池 中 。 





Toast 显 示 以 后 ，NMS 还 会 通过 scheduleTimeoutLocked 方 法 来 发 送 
一 个 延 时 消息 ， 具 体 的 延 时 取决 于 Toast 的 时 长 ， 如 下 所 示 。 





long delay = r.duration == Toast.LENGTH_LONG ? LONG_DELAY 


mHandler .sendMessageDelayed(m, delay); 


在 上 面 的 代码 中 ，LONG_DELAY 是 3.5s， 而 SHORT_DELAY 是 
2s。 延 迟 相应 的 时 间 后 ，NMS 会 通过 cancelToastLocked 方 法 来 隐藏 Toast 
并 将 其 从 mToastQueue 中 移 除 ， 这 个 时 候 如 果 mToastQueue 中 还 有 其 他 
Toast， 那 么 NMS 就 继续 显示 其 他 Toast。 


Toast 的 隐藏 也 是 通过 ToastRecord 的 callback 来 完成 的 ， 这 同样 也 是 
一 次 IPC 过 程 ， 它 的 工作 方式 和 Toast 的 显示 过 程 是 类 似 的 ， 如 下 所 示 。 





try { 
record.callback.hide(); 
} catch (RemoteException e) { 
Slog.w(TAG, "Object died trying to hide notification " + r 
+ " in package " + record.pkg); 
// don't worry about this,we're about to remove it from 


// the list anyway 





通过 上 面 的 分 析 ， 大 家 知道 Toast 的 显示 和 影响 过 程 实际 上 是 通过 
Toast 中 的 TN 这 个 类 来 实现 的 ， 它 有 两 个 方法 show 和 hide， 分 别 对 应 
Toast 的 显示 和 隐藏 。 由 于 这 两 个 方法 是 被 NMS 以 路 进程 的 方式 调用 
的 ， 因 此 它们 运行 在 Binder 线 程 池 中 。 为 了 将 执行 环境 切换 到 Toast 请 求 
所 在 的 线程 ， 在 它们 的 内 部 使 用 了 Handler， 如 下 所 示 。 





JAX 





上 述 代码 中 ，mShow 和 mHide 是 两 个 Runnable， 它 们 内 部 分 别 调用 
了 handleShow 和 handleHide 方 法 。 由 此 可 见 ，handleShow 和 handleHide 才 





是 真正 完成 显示 和 隐藏 Toast 的 地 方 。TN 的 handleShow 中 会 将 Toast 的 祝 
图 添加 到 Window 中 ， 如 下 所 示 。 


而 NT 的 handleHide 中 会 将 Toast 的 视图 从 Window 中 移 除 ， 如 下 所 


| 


if (localLOGV) Log.v(TAG, "REMOVE! " + mView + " in " + th 
mwM. removeView(mView) ; 


} 


到 这 里 Toast 的 Window 的 创建 过 程 已 经 分 析 完 了 ， 相 信 读 者 对 Toast 
的 工作 过 程 有 了 一 个 更 加 全 面 的 理解 了 。 除 了 上 面 已 经 提 到 的 
Activity、Dialog 和 Toast 以 外 ，PopupWindow、 菜 单 以 及 状态 栏 等 都 是 
通过 Window 来 实现 的 ， 这 里 就 不 一 一 介绍 了 ， 读 者 可 以 找 自己 感 兴趣 
的 内 容 来 分 析 。 


本 章 的 意义 在 于 让 读者 对 Window 有 一 个 更 加 清晰 的 认识 ， 同 时 能 
够 深刻 理解 Window 和 View 的 依赖 关系 ， 这 有 助 于 理解 其 他 更 深层 次 的 
概念 ， 比 如 SurfaceFlinger。 通 过 本 章 读者 应 该 知道 ， 任 何 View 都 是 附属 
在 一 个 window 上 面 的 ， 那 么 这 里 问 一 个 问题 : 一 个 应 用 中 到 底 有 多 少 
个 Window 呢 ?相信 读者 都 已 经 清楚 了 。 





SIS ”四 大 组 件 的 工作 过 程 


本 章 讲述 Android 中 的 四 大 组 件 的 工作 过 程 。 说 到 四 大 组 件 ， 开 发 
者 都 再 熟悉 不 过 了 ， 它 们 是 Activity、Service、BroadcastReceiver 和 
ContentProvider。 如 何 使 用 四 大 组 件 ， 这 不 是 本 章 关 心 的 ， 毕 竟 这 是 开 
发 者 都 熟悉 的 内 容 ， 本 章 按 照 如 下 的 逻辑 来 分 析 Android 的 四 大 组 件 : 

自 先 会 对 四 大 组 件 的 运行 状态 和 工作 方式 做 一 个 概括 化 的 描述 ， 接 着 对 
四 大 组 件 的 工作 过 程 进行 分 析 ， 通 过 本 章 的 分 析 读 者 可 以 对 四 大 组 件 有 
一 个 更 深刻 的 认识 。 





本 章 主 要 侧重 于 四 大 组 件 工作 过 程 的 分 析 ， 通 过 分 析 它 们 的 工作 过 
程 我 们 可 以 更 好 地 理解 系统 内 部 的 运行 机 制 。 本 章 的 意义 在 于 加 深 读 者 
对 四 大 组 件 的 工作 方式 的 认识 ， 由 于 四 大 组 件 的 特殊 性 ， 我 们 有 必要 对 
它们 的 工作 过 程 有 一 定 的 了 解 ， 这 也 有 助 于 加 深 对 Android 整 体 的 体系 
结构 的 认识 。 很 多 情况 下 ， 只 有 对 Android 体 系 结构 有 一 定 认 识 ， 在 实 
际 的 开发 中 才能 写 出 优秀 的 代码 。 








9.1 四 六 组 件 的 运行 状态 


Android 的 四 大 组 件 中 除了 BroadcastReceiver 以 外 ， 其 他 三 种 组 件 都 
必须 在 Android-Manifest 中 注册 ， 对 于 BroadcastReceiver 来 说 ， 它 既 可 以 
在 AndroidManifest 中 注册 也 可 以 通过 代码 来 注册 。 在 调用 方式 上 ， 
Activity、Service 和 BroadcastReceiver 需 要 借助 Intent， 而 ContentProvider 
则 无 须 借 助 Intent。 





Activity 是 一 种 展示 型 组 件 ， 用 于 加 用 户 直 接地 展示 一 个 界面 ， 并 
且 可 以 接收 用 户 的 输入 信息 从 而 进行 交互 。Activity 是 最 重要 的 一 种 组 
件 ， 对 用 户 来 说 ，Activity 就 是 一 个 Android 应 用 的 全 部 ， 这 是 因为 其 他 
三 大 组 件 对 用 户 来 说 都 是 不 可 感知 的 。Activity 的 启动 由 Intent 触 发 ， 其 
中 Intent 可 以 分 为 显 式 Intent 和 隐 式 Intent， 显 式 Intent 可 以 明确 地 指向 一 
个 Activity 组 件 ， 隐 式 Intent 则 指向 一 个 或 多 个 目标 Activity 组 件 ， 当 然 也 
可 能 没有 任何 一 个 Activity 组 件 可 以 处 理 这 个 隐 式 Intent。 一 个 Activity 组 
件 可 以 具有 特定 的 启动 模式 。 关 于 Activity 的 启动 模式 在 第 1 章 中 己 经 做 
了 介绍 ， 同 一 个 Activity 组 件 在 不 同 的 启动 模式 下 会 有 不 同 的 效果 。 
Activity 组 件 是 可 以 停止 的 ， 在 实际 开发 中 可 以 通过 Activity 的 finish 方 法 
来 结束 一 个 Activity 组 件 的 运行 。 由 此 来 看 ，Activity 组 件 的 主要 作用 是 
展示 一 个 界面 并 和 用 户 交 互 ， 它 扮演 的 是 一 种 前 台 界 面 的 角色 。 

















Service 是 一 种 计算 型 组 件 ， 用 于 在 后 台 执 行 一 系列 计算 任务 。 由 于 
Service 组 件 工 作 在 后 台 ， 因 此 用 户 无 法 直接 感知 到 它 的 存在 。Service 组 
件 和 Activity 组 件 略 有 不 同 ，Activity 组 件 只 有 一 种 运行 模式 ， 即 Activity 
处 于 启动 状态 ， E PAEA A : 局 动 状 态 和 绑 定 状态 。 

当 Service 组 件 处 于 局 动 状态 时 ， 这 个 时 候 Service 内 部 可 以 做 一 些 后 台 计 











算 ， 并 且 不 需要 和 外 界 有 直接 的 交互 。 尽 管 Service 组 件 是 用 于 执行 后 台 
计算 的 ， 但 是 它 本 身 是 运行 在 主线 程 中 的 ， 因 此 耗 时 的 后 台 计 算 仍然 需 
要 在 单独 的 线程 中 去 完成 。 当 Service 组 件 处 于 绑 定 状态 时 ， 这 个 时 候 
Service 内 部 同样 可 以 进行 后 台 计 算 ， 但 是 处 于 这 种 状态 时 外 界 可 以 很 方 
便 地 和 Service 组 件 进行 通信 。Service 组 件 也 是 可 以 停止 的 ， 停 止 一 个 
Service 组 件 稍 显 复杂 ， 需 要 有 灵活 采用 stopService 和 unBindService 这 两 个 
方法 才能 完全 停止 一 个 Service 组 件 。 




















BroadcastReceiver 是 一 种 消息 型 组 件 ， 用 于 在 不 同 的 组 件 乃 至 不 同 
的 应 用 之 间 传 递 消 息 。BroadcastReceiver 同 样 无 法 被 用 户 直接 感知 ， 
为 它 工作 在 系统 内 部 。BroadcastReceiver 也 叫 广播 ， 广 播 的 注册 有 两 种 
方式 : 静态 注册 和 动态 注册 。 静 态 注 册 是 指 在 AndroidManifest 中 注册 广 
播 ， 这 种 广播 在 应 用 安装 时 会 被 系统 解析 ， 此 种 形式 的 广播 不 需要 应 用 
启动 就 可 以 收 到 相应 的 广播 。 动 态 注 册 广 播 需 要 通过 
Context.registerReceiver() 来 实现 ， 并 且 在 不 需要 的 时 候 要 通过 
Context.unRegisterReceiver() 来 解除 广播 ， 此 种 形态 的 广播 必须 要 应 用 局 
动 才能 注册 并 接收 广播 ， 因 为 应 用 不 启动 就 无 法 注册 广播 ， 无 法 注册 广 
播 束 无 法 收 到 相应 的 广播 。 在 实际 开发 中 通过 Context 的 一 系列 send 方 法 
来 发 送 广播 ， 被 发 送 的 广播 会 被 系统 发 送 给 感 兴趣 的 广播 接收 者 ， 发 送 
和 接收 过 程 的 匹配 是 通过 广播 接收 者 的 <intent-filter> 来 描述 的 。 可 以 发 
现 ，BroadcastReceiver 组 件 可 以 用 来 实现 低 耦 合 的 观察 者 模式 ， 观 察 者 
和 被 观察 者 之 间 可 以 没有 任何 耦合 。 由 于 BroadcastReceiver 的 特性 ， 它 
不 适合 用 来 执行 耗 时 操作 。BroadcastReceiver 组 件 一 般 来 说 不 需要 停 
止 ， 它 也 没有 停止 的 概念 。 











ContentProvider 是 一 种 数据 共享 型 组 件 ， 用 于 加 其 他 组 件 乃 至 其 他 
应 用 共享 数据 。 和 了 BroadcastReceiver 一 样 ，ContentProvider 同 样 无 法 被 用 


户 直接 感知 。 对 于 一 个 ContentProvider 组 件 来 说 ， 它 的 内 部 需要 实现 增 
删改 查 这 四 种 操作 ， 在 它 的 内 部 维持 着 一 份 数据 集合 ， 这 个 数据 集合 既 
可 以 通过 数据 库 来 实现 ， 也 可 以 采用 其 他 任何 类 型 来 实现 ， 比 如 List 和 
Map，ContentProvider 对 数据 集合 的 具体 实现 并 没有 任何 要 求 。 需 要 注 
意 的 是 ，ContentProvider 内 部 的 insert、delete、update 和 query 方 法 需要 处 
理 好 线程 同步 ， 因 为 这 几 个 方法 是 在 Binder 线 程 池 中 被 调用 的 ， 另 外 
ContentProvider 组 件 也 不 需要 手动 停止 。 


9.2 ”Activity 的 工作 过 程 


本 节 讲 述 的 内 容 是 Activity 的 工作 过 程 。 为 了 方便 日 第 的 开发 工 
作 ， 系 统 对 四 大 组 件 的 工作 过 程 进行 了 很 大 程度 的 封装 ， 这 使 得 开发 着 
无 须 关 注 实 现 细 市 即 可 快速 地 使 用 四 大 组 件 。Activity 作 为 很 重要 的 一 
个 组 件 ， 其 内 部 工作 过 程 系统 当然 也 是 做 了 很 多 的 封装 ， 这 种 封装 使 得 
局 动 一 个 Activity 变 得 异 冲 简单 。 在 显 式 调用 的 情形 下 ， 只 需要 通过 如 
下 代码 即 可 完成 : 








Intent intent = new Intent(this, TestActivity.class); 


startActivity(intent); 


iow EMS ay ao AA Activity, Aja Activity 
被 系统 启动 并 展示 在 用 户 的 眼前 。 这 个 过 程 对 于 Android 开 发 者 来 说 最 
普通 不 过 了 ， 这 也 是 很 理 所 应 当 的 事 ， 但 是 有 没有 想 过 系统 内 部 到 底 是 
如 何 启 动 一 个 Activity 的 呢 ?” 比 如 新 Activity 的 对 象 是 在 何 时 创建 的 ? 
Activity 的 onCreate 方 法 又 是 在 何 时 被 系统 回调 的 呢 ? 读者 可 能 会 有 疑 
问 : 在 日 常 开发 中 并 不 需要 了 解 Activity 底 层 到 底 是 怎么 工作 的 ， 那 么 
了 解 它们 又 有 什么 意义 呢 ? 没 错 ， 在 日 常 开发 中 是 不 需要 了 解 系 统 的 底 
层 工 作 原 理 ， 但 是 如 果 想 要 在 技术 上 有 进一步 的 提高 ， 那 么 就 必须 了 解 
一 些 系 统 的 工作 原理 ， 这 是 一 个 开发 人 员 日 后 成 长 为 高 级 工程 师 乃 至 架 
构 师 所 必须 具备 的 技术 能 力 。 从 另外 一 个 角度 来 说 ，Android 作 为 一 个 
优秀 的 基于 Linux 的 移动 操作 系统 ， 其 内 部 一 定 有 很 多 值得 我 们 学 习 和 
首 鉴 的 地 方 ， 因 此 了 解 系统 的 工作 过 程 就 是 学 习 Android 操 作 系 统 。 通 
过 对 Android 操 作 系 统 的 学 习 可 以 提高 我 们 对 操作 系统 在 技术 实现 上 的 
理解 ， 这 对 于 加 强 开发 人 员 的 内 功 是 很 有 帮助 的 。 但 是 有 一 点 ， 由 于 
































Android 的 内 部 实现 多 数 都 比较 复杂 ， 在 研究 内 部 实现 上 应 该 更 加 侧重 
于 对 整体 流程 的 把 握 ， 而 不 能 深入 代码 细节 不 能 自拔 ， 太 深入 代码 细节 
往往 会 导致 * 只 见 树木 不 见 和 森林 ”的 状态 。 处 于 这 种 状态 下 ， 无 法 对 整体 
流程 建立 足够 的 认识 ， 取 而 代 之 的 是 烦琐 的 代码 细节 ， 但 是 代码 细节 本 
吴 并 不 具有 太 多 的 指导 意义 ， 因 此 这 种 学 习 状态 是 要 极力 避免 的 。 鉴 于 
这 一 点 ， 本 章 对 Activity 以 及 其 他 三 个 组 件 的 工作 过 程 的 分 析 将 会 侧重 
于 整体 流程 的 讲解 ， 目 的 是 为 了 让 读者 对 四 大 组 件 的 工作 过 程 有 一 个 感 
性 的 认识 并 能 够 给 予 上 层 开 发 一 些 指导 意义 。 但 凡事 不 是 绝对 的 ， 如 果 
开发 者 从 事 的 工作 是 Android Rom 开发 ， 那 底层 代码 细节 还 是 要 有 所 涉 
JE H o 











本 节 主 要 分 析 Activity 的 启动 过 程 ， 通 过 本 节 读 者 可 以 对 Activity 的 
启动 过 程 有 一 个 感性 的 认识 ， 至 于 启动 模式 以 及 任务 栈 等 概念 本 节 中 并 
未 涉及 ， 读 者 感 兴趣 的 话 可 以 查看 相应 的 代码 细节 即 可 。 





我 们 从 Activity 的 startActivity 方 法 开始 分 析 ，startActivity 方 法 有 好 
几 种 重 载 方式 ， 但 它们 最 终 都 会 调用 startActivityForResult 方 法 ， 它 的 实 
现 如 下 所 示 。 


public void startActivityForResult(Intent intent,int requestc 
@Nullable Bundle options) { 
if (mParent == null) { 
Instrumentation.ActivityResult ar = 
mInstrumentation.execStartActivity( 
this,mMainThread.getApplicationTh 
intent, requestCode, options); 
if (ar != null) { 


mMainThread.sendActivityResult ( 





if (options != null && !isTopOfTask()) { 


mActivityTransitionState.startExitOutTransition(t 


在 上 面 的 代码 中 ， 我 们 只 需要 关注 mParent == null 这 部 分 逻辑 即 
可 。mpParent 代 表 的 是 ActivityGroup，ActivityGroup 最 开始 被 用 来 在 一 个 
FA PRA * -F Activity, (AE EAPI 13 中 已 经 被 废 齐 了 ， 系 统 推荐 
采用 Fragment 来 代替 ActivityGroup，Fragment 的 好 处 就 不 用 多 说 了 。 在 
上 面 的 代码 中 需要 注意 mMainThread.getApplicationThread() 这 个 参数 ， 
它 的 类 型 是 ApplicationThread，ApplicationThread 是 ActivityThread 的 一 
个 内 部 类 ， 通 过 后 面 的 分 析 可 以 发 现 ，ApplicationThread 和 
ActivityThread 在 Activity 的 启动 过 程 中 发 挥 着 很 重要 的 作用 。 接 着 看 一 
下 Instrumentation 的 execStartActivity 方 法 ， 如 下 所 示 。 








public ActivityResult execStartActivity( 
Context who, IBinder contextThread, IBinder token,A 
Intent intent,int requestCode, Bundle options) { 
TApplicationThread whoThread = (IApplicationThread) conte 
if (mActivityMonitors != null) { 
synchronized (mSync) { 
final int N = mActivityMonitors.size(); 
for (int i=0; i<N; i++) { 
final ActivityMonitor am = mActiv 
if (am.match(who,null,intent)) { 
am.mHits++; 


if (am.isBlocking()) { 





从 上 面 的 代码 可 以 看 出 ， 启 动 Activity 真 正 的 实现 由 
ActivityManagerNative.getDefault() 的 startActivity 方 法 来 完成 。 
ActivityManagerService 〈 下 面 简称 为 AMS ) 继承 上 自 
ActivityManagerNative， 而 ActivityManagerNative 继 承 自 Binder 并 实现 了 
IActivityManager 这 个 Binder 接 口 ， 因 此 AMS 也 是 一 个 Binder， 它 是 
IActivityManager 的 具体 实现 。 由 于 ActivityManagerNative.getDefaultO 其 





实 是 一 个 IActivityManager 类 型 的 Binder 对 象 ， 因 此 它 的 具体 实现 是 
AMS。 可 以 发 现 ， 在 ActivityManagerNative 中 ，AMS 这 个 Binder 对 象 采 
用 单 例 模式 对 外 提供 ，Singleton 是 一 个 单 例 的 封装 类 ， 第 一 次 调用 它 的 
get 方 法 时 它 会 通过 create 方 法 来 初始 Hees 这 个 Binder 对 象 ， 在 后 续 的 
调用 中 则 直接 返回 之 前 创建 的 对 象 ， 这 个 过 程 的 源码 如 下 所 示 。 


static public IActivityManager getDefault() { 
return gDefault.get(); 
} 
private static final Singleton<IActivityManager> gDefault = n 
protected IActivityManager create() { 
IBinder b = ServiceManager .getService("activity") 
if (false) { 
Log.v("ActivityManager", "default service 
} 
IActivityManager am = asInterface(b); 
if (false) { 
Log.v("ActivityManager", "default service 


$ 


return am; 


$ 


从 上 面 的 分 析 可 以 知道 ，Activity 由 
ActivityManagerNative.getDefault0 来 启动 ， 而 
ActivityManagerNative.getDefault() 实 际 上 el ， 因 此 Activity 的 启动 过 
程 又 转移 到 了 AMS 中 ， 为 了 继续 分 析 这 个 过 程 ， 只 需要 查看 AMS 的 





startActivity 方 法 即 可 。 在 分 析 AMS 的 的 startActivity 方 法 之 前 ， 我 们 先 回 
过 头 来 看 一 下 Instrumentation 的 execStartActivity 方 法 ， 其 中 有 一 行 代 

人 码 : checkStartActivityResult(result,intent)， 直 观 上 看 起 来 这 个 方法 的 作 
用 像 是 在 检查 启动 Activity 的 结果 ， 它 的 具体 实现 如 下 所 示 。 





/** @hide */ 
public static void checkStartActivityResult(int res,Object in 
if (res => ActivityManager.START_SUCCESS) { 
return; 
J 
switch (res) { 
case ActivityManager .START_INTENT_NOT_RESOLVED: 
case ActivityManager .START_CLASS_NOT_FOUND: 
if (intent instanceof Intent && ((Intent) 
throw new ActivityNotFoundExcepti 
"Unable to find e 
+ ((Intent)intent 
+ "; have you dec 
throw new ActivityNotFoundException( 
"No Activity found to han 
case ActivityManager .START_PERMISSION_DENIED: 
throw new SecurityException("Not allowed 
+ intent); 
case ActivityManager .START_FORWARD_AND_REQUEST_CO 
throw new AndroidRuntimeException( 
"FORWARD_RESULT_FLAG used 


case ActivityManager .START_NOT_ACTIVITY: 


throw new IllegalArgumentException( 
"PendingIntent is not an 
case ActivityManager .START_NOT_VOICE_COMPATIBLE: 
throw new SecurityException( 
"Starting under voice con 
default: 
throw new AndroidRuntimeException( "Unknow 


+ res + " when starting " 


从 上 面 的 代码 可 以 看 出 ，checkStartActivityResult 的 作用 很 明显 ， 就 
是 检查 启动 Activity 的 结果 。 当 无 法 正确 地 局 动 一 个 Activity 时 ， 这 个 方 
法 会 抛 出 异常 信息 ， 其 中 最 熟悉 不 过 的 就 是 “Unable to find explicit 
activity class; have you declared’ this activity in your 
AndroidManifest.xml?” 这 个 异常 了 ， 当 待 局 动 的 Activity 没 有 在 
AndroidManifest 中 注册 时 ， 束 会 抛 出 这 个 异常 。 


接着 我 们 继续 分 析 AMS 的 startActivity 方 法 ， 如 下 上 所 示 。 


public final int startActivity(IApplicationThread caller,Stri 

Intent intent,String resolvedType, IBinder resultT 

int startFlags,ProfileriInfo profileriInfo, Bundle o 

return startActivityAsUser (caller, callingPackage, intent,r 

resultwho, requestCode, startFlags, profileriInfo, opt 
UserHandle.getCallingUserId()); 


} 
public final int startActivityAsUser(IApplicationThread calle 


Intent intent,String resolvedType, IBinder resultT 
int startFlags,ProfileriInfo profileriInfo, Bundle o 
enforceNotIsolatedCaller("startActivity"); 
userId = handleIncomingUser (Binder .getCallingPid(),Binder 
false, ALLOW_FULL_ONLY, "startActivity", nul 
// TODO: Switch to user app stacks here. 
return mStackSupervisor.startActivityMayWait(caller,-1,ca 
resolvedType, null, null, resultTo, resultwho 


profileriInfo, null, null, options, userId, nul 


可 以 看 出 ，Activity 的 局 动 过 程 叉 转移 到 了 ActivityStackSupervisor 的 
startActivity-MayWait 方 法 中 了 ， 在 startActivityMayWait 中 又 调用 了 
startActivityLocked 方 法 ， 然 后 startActivityLocked 方 法 又 调用 了 
startActivityUncheckedLocked 方 法 ， 接 着 startActivityUncheckedLocked 义 
调用 了 ActivityStack 的 resumeTopActivitiesLocked 方 法 ， 这 个 时 候 启 动 过 
程 已 经 从 ActivityStackSupervisor 转 移 到 了 ActivityStack。 


ActivityStack 的 resumeTopActivitiesLocked 方 法 的 实现 如 下 所 示 。 


final boolean resumeTopActivityLocked(ActivityRecord prev, Bun 
if (inResumeTopActivity) { 
// Don't even start recursing. 
return false; 


} 


boolean result = false; 


try { 


// Protect against recursion. 


inResumeTopActivity = true; 

result = resumeTopActivityInnerLocked(prev, option 
} finally { 

inResumeTopActivity = false; 


} 


return result; 


从 上 面 的 代码 可 以 看 出 ，resumeTopActivityLocked 调 用 了 
resumeTopActivityInnerLocked 方 法 ，resumeTopActivityInnerLocked 方 法 
又 调用 了 ActivityStackSupervisor 的 startSpecificActivityLocked 方 法 ， 
startSpecificActivityLocked 的 源码 如 下 所 示 。 


void startSpecificActivityLocked(ActivityRecord r, 
boolean andResume, boolean checkConfig) { 
// Is this activity's application already running? 
ProcessRecord app = mService.getProcessRecordLocked(r.pro 
r.info.applicationInfo.uid, true); 
r.task.stack.setLaunchTime(r); 
if (app != null && app.thread != null) { 
try { 
if ((r.info.flags&ActivityInfo.FLAG MULTI 
|| !"android".equals(r.in 
// Don't add this if it is a plat 
// to run in multiple processes,b 
// part of the framework so doesn 


// separate apk in the process. 





从 上 面 代码 可 以 看 出 ，startSpecificActivityLocked 方 法 调用 了 
realStartActivityLocked 方 法 。 为 了 更 清晰 地 说 明 Activity 的 启动 过 程 在 
ActivityStackSupervisor 和 ActivityStack 之 间 的 传递 顺序 ， 这 里 给 出 了 一 
张 流程 图 ， 如 图 9-1 所 示 。 
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图 9-1 Activity 的 启动 过 程 在 ActivityStackSupervisor 和 ActivityStack 之 间 的 传递 顺序 


在 ActivityStackSupervisor 的 realStartActivityLocked 方 法 中 有 如 下 一 
段 代 码 : 


app.thread.scheduleLaunchActivity(new Intent(r.intent),r.appT 
System.identityHashCode(r),r.info,new Configurati 
r.compat,r.task.voiceInteractor,app.repProcState, 
results, newIntents, !andResume, mService.isNextTran 


profileriInfo); 


上 面 的 这 段 代码 很 重要 ， 其 中 app.thread 的 类 型 为 
IApplicationThread，IApplicationThread 的 声明 如 下 : 


public interface IApplicationThread extends IInterface { 


void schedulePauseActivity(IBinder token, boolean finished, boo 
int configChanges,boolean dontReport) throws RemoteE 
void scheduleStopActivity(IBinder token, boolean showWindow, 
int configChanges) throws RemoteException; 
void scheduleWindowVisibility(IBinder token, boolean showWindo 
RemoteException; 
void scheduleSleeping(IBinder token, boolean sleeping) throws 
void scheduleResumeActivity(IBinder token,int procState, 
isForward, Bundle resumeArgs) 
throws RemoteException; 
void scheduleSendResult(IBinder token, List<ResultInfo> r 
RemoteException; 
void scheduleLaunchActivity(Intent intent, IBinder token, 
ActivityInfo info,Configuration curConfig, Compat 
compatinfo, 
IVoiceInteractor voiceInteractor,int procState,B 
PersistableBundle persistentState, List<ResultIinf 
List<Intent> pendingNewIntents, boolean notResume 
isForward, 
ProfilerInfo profileriInfo) throws RemoteExceptio 
void scheduleRelaunchActivity(IBinder token, List<ResultI 
Results, 
List<Intent> pendingNewIntents, int configChanges 
boolean notResumed, Configuration config) throws 
void scheduleNewIntent(List<Intent> intent,IBinder token 
RemoteException; 


void scheduleDestroyActivity(IBinder token,boolean finis 


int configChanges) throws RemoteException; 
void scheduleReceiver(Intent intent,ActivityInfo info, Co 
Info compatinfo, 
int resultCode,String data, Bundle extras, boolean 
int sendingUser,int processState) throws RemoteE 
static final int BACKUP_MODE_INCREMENTAL = 0; 
static final int BACKUP_MODE_FULL = 1; 
static final int BACKUP_MODE_RESTORE = 2; 
static final int BACKUP_MODE_RESTORE_FULL = 3; 
void scheduleCreateBackupAgent(ApplicationInfo app,Compa 
compatinfo, 
int backupMode) throws RemoteException; 
void scheduleDestroyBackupAgent(ApplicationInfo app, Comp 
compatinfo) 
throws RemoteException; 
void scheduleCreateService(IBinder token,ServiceInfo inf 
CompatibilityInfo compatInfo,int processState) t 
RemoteException; 
void scheduleBindService(IBinder token, 
Intent intent,boolean rebind,int processState) t 
RemoteException; 
void scheduleUnbindService(IBinder token, 
Intent intent) throws RemoteException; 
void scheduleServiceArgs(IBinder token, boolean taskRemov 
StartId ， 
int flags,Intent args) throws RemoteException; 


void scheduleStopService(IBinder token) throws RemoteExc 


} 


因为 它 继 承 了 IInterface 接 口 ， 所 以 它 是 一 个 Binder 类 型 的 接口 。 从 
IApplicationThread 声 明 的 接口 方法 可 以 看 出 ， 其 内 部 包含 了 大 量 局 动 、 
停止 Activity 的 接口 ， 此 外 还 包含 了 启动 和 停止 服务 的 接口 。 从 接口 方 
法 的 命名 可 以 猜测 ，IApplicationThread 这 个 Binder 接 口 的 实现 者 完成 了 
大 量 和 Activity 以 及 Service 启 动 /停止 相关 的 功能 ， 事 实证 明 的 确 是 这 样 
的 。 


那么 IApplicationThread 的 实现 者 到 底 是 什么 呢 ? 答案 就 是 
ActivityThread 中 的 内 部 类 ApplicationThread， 下 面 来 看 一 下 
ApplicationThread 的 定义 ， 如 下 所 示 。 


private class ApplicationThread extends ApplicationThreadNati 
public abstract class ApplicationThreadNative extends Binder 


implements IApplicationThread 


可 以 看 出 ，ApplicationThread 继 承 了 ApplicationThreadNative， 而 
ApplicationThreadNative 则 继承 了 Binder 并 实现 了 IApplicationThread 接 
口 。 如 果 读 者 还 记得 系统 为 AIDL 文 件 自动 生成 的 代码 ， 就 会 发 现 
ApplicationThreadNative 的 作用 其 实 和 系统 为 AIDL 文 件 生成 的 类 是 一 样 
的 ， 这 方面 的 知识 在 第 2 章 已 经 做 了 介绍 ， 读 者 可 以 但 看 第 2 间 的 相关 内 


J 


容 。 





ta 的 内 部 ， 人 
类 ， 这 个 类 的 实现 如 下 所 示 。 相 信 读 者 有 一 种 似曾相识 的 感觉 ， 其 实 这 
个 内 i 目 动 生成 的 代理 类 。 种 种 迹象 表明 ， 





ApplicationThreadNative 就 是 IApplicationThread 的 实现 者 ， 由 于 
ApplicationThreadNative 被 系统 定义 为 抽象 类 ， 所 以 ApplicationThread 惑 
成 了 IApplicationThread 最 终 的 实现 者 。 


class ApplicationThreadProxy implements IApplicationThread { 
private final IBinder mRemote; 
public ApplicationThreadProxy(IBinder remote) { 
mRemote = remote; 
} 
public final IBinder asBinder() { 
return mRemote; 
} 
public final void schedulePauseActivity(IBinder token, bo 
boolean userLeaving,int configChanges,boolean do 
throws RemoteException { 
Parcel data = Parcel.obtain(); 
data.writeInterfaceToken(IApplicationThread.descript 
data.writeStrongBinder (token); 
data.writeInt(finished ? 1 : 0); 
data.writeInt(userLeaving ? 1 :0); 
data.writeInt(configChanges); 
data.writeInt(dontReport ? 1 : 0); 
mRemote. transact (SCHEDULE_PAUSE_ACTIVITY_TRANSACTION 
IBinder .FLAG_ONEWAY) ; 
data.recycle(); 


} 
public final void scheduleStopActivity(IBinder token, boo 


int configChanges) throws RemoteException { 

Parcel data = Parcel.obtain(); 
data.writeInterfaceToken(IApplicationThread.descript 
data.writeStrongBinder (token) ; 
data.writeInt(showwWindow ? 1 : 0); 
data.writeInt(configChanges) ; 
mRemote. transact (SCHEDULE_STOP_ACTIVITY_TRANSACTION, 

IBinder .FLAG_ONEWAY ) ; 


data.recycle(); 





RIKE, Activity aa tE [a] #) y ApplicationThread# , 
ApplicationThread 通 过 scheduleLaunchActivity 方 法 来 启动 Activity， 代 码 
如 下 所 示 。 


// we use token to identify this activity without having to s 
// activity itself back to the activity manager. (matters mor 
public final void scheduleLaunchActivity(Intent intent, IBinde 
ActivityInfo info,Configuration curConfig, Compati 
IVoiceInteractor voiceInteractor,int procState, Bu 
PersistableBundle persistentState, List<ResultInfo 
List<Intent> pendingNewIntents, boolean notResumed 
ProfilerInfo profileriInfo) { 
updateProcessState(procState, false); 


ActivityClientRecord r = new ActivityClientRecord(); 


在 ApplicationThread 中 , 人 民 简 单 ， 就 
oM 启动 Activity 的 消息 交 由 Handler 处 理 ， 这 个 Handler 有 着 一 个 
很 简洁 的 名 字 : HH。sendMessage 的 作用 是 发 送 一 个 消息 给 了 HH 处 理 ， 它 的 
实现 如 下 所 示 。 





接着 来 看 一 下 Handler H 对 消息 的 处 理 ， 如 下 所 示 。 





从 Handler H 对 “LAUNCH_ACTIVITY” 这 个 消息 的 处 理 可 以 知道 ， 
Activity 的 启动 过 程 由 ActivityThread 的 handleLaunchActivity 方 法 来 实 





现 ， 它 的 源码 如 下 所 示 。 





从 上 面 的 源码 可 以 看 出 ，performLaunchActivity 方 法 最 终 完 成 了 
Activity 对 象 的 创建 和 启动 过 程 ， 并 且 ActivityThread 通 过 
handleResumeActivity 方 法 来 调用 被 启动 Activity 的 onResume 这 一 生命 周 
期 方法 。 


performLaunchActivity 这 个 方法 主要 完成 了 如 下 几 件 事 。 


1. 从 ActivityClientRecord 中 获取 待 启动 的 Activity 的 组 件 信 息 





r.packageInfo = getPackageInfo(aiInfo.applicationInfo,r.co 
Context .CONTEXT_INCLUDE_CODE) ; 
} 
ComponentName component = r.intent.getComponent(); 
if (component == null) { 
component = r.intent.resolveActivity( 
mInitialApplication.getPackageManager()); 
r.intent.setComponent (component); 
} 
if (r.activityInfo.targetActivity != null) { 
component = new ComponentName(r.activityInfo.packageName, 


r.activityInfo.targetActivity); 


2. 通过 Instrumentation 的 newActivity 方 法 使 用 类 加 载 器 创建 
Activity 对 象 


Activity activity = null; 

try { 
java.lang.ClassLoader cl = r.packageInfo.getClassLoader () 
activity = mInstrumentation.newActivity( 

cl,component.getClassName(),r.intent); 

StrictMode.incrementExpectedActivityCount(activity.getCla 
r.intent.setExtrasClassLoader(cl); 
r.intent.prepareToEnterProcess()j; 
if (rstate != null) { 


r.state.setClassLoader(cl); 





至 于 Instrumentation 的 newActivity， 它 的 实现 比较 简单 ， 就 是 通过 
类 加 载 嚣 来 创建 Activity 对 象 : 





3. 通过 LoadedApk 的 makeApplication 方 法 来 尝试 创建 Application 





String appClass = mApplicationInfo.className; 
if (forceDefaultAppClass || (appClass == null)) { 


appClass = "android.app.Application"; 


try { 


java.lang.ClassLoader cl = getClassLoader(); 
if (!mPackageName.equals("android")) { 
initializeJavaContextClassLoader(); 
} 
ContextImpl appContext = ContextImpl.createAppCon 
app = mActivityThread.mInstrumentation.newApplica 
cl,appClass, appContext); 
appContext.setOuterContext (app); 
} catch (Exception e) { 
if (!mActivityThread.mInstrumentation.onException 
throw new RuntimeException( 
"Unable to instantiate applicatio 


+": " + e,toString(),e); 


} 
mActivityThread.mAllApplications.add(app); 


mApplication = app; 
if (instrumentation != null) { 
try { 
instrumentation.callApplicationOnCreate(a 
} catch (Exception e) { 


if (!instrumentation.onException(app,e) ) 


throw new RuntimeException( 
"Unable to create applica 


+": " + e.toString(),e); 


return app; 


从 makeApplication 的 实现 可 以 看 出 ， 如 果 Application 已 经 被 创建 过 
了 ， 那 么 就 不 会 再 重复 创建 了 ， em 只有 二 
Application 象 。Application 对 象 的 创建 也 是 通 on E a 完成 
的 ， 这 个 过 程 和 Activity 对 象 的 创建 一 样 ， 都 是 通过 类 加 载 器 来 实现 
的 。Application 创 建 完毕 后 ， 系 统 会 通过 Instrumentation 的 
callApplicationOnCreate 来 调用 Application 的 onCreate 方 法 。 


.创建 ContextImpl 对 象 并 通过 Activity 的 attach 方 法 来 完成 一 些 重 
要 数 的 初始 化 


Context appContext = createBaseContextForActivity(r,activity) 
CharSequence title = r.activityInfo.loadLabel(appContext.getP 
Configuration config = new Configuration(mCompatConfiguration 
if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity " 
+ r.activityInfo.name + " with config " + config) 
activity.attach(appContext, this, getInstrumentation(),r.token, 
r.ident,app,r.intent,r.activityInfo, title, r.paren 


r.embeddedID, r.lastNonConfigurationiInstances, conf 


r.voiceInteractor); 





ContextImpl 是 一 个 很 重要 的 数据 结构 ， 它 是 Context 的 具体 实现 ， 
Context 中 的 大 部 分 逻辑 都 是 由 ContextImpl 来 完成 的 。ContextImpl 是 通 
过 Activity 的 attach 方 法 来 和 Activity 建 立 关联 的 ， 除 此 以 外 ， eaae 
法 中 Activity 还 会 完成 Window 的 创建 并 建立 自己 和 Window 的 关联 ， 这 样 
当 Window 接 收 到 外 部 输入 事件 后 就 可 以 将 事件 传递 给 Activity。 


5. 调用 Activity 的 onCreate 方 法 


noi Aenea ey On Greate (ac any state), HH FActivity 
的 onCreate 已 经 被 调用 ， 这 也 意味 着 Activity 已 经 完成 了 整个 启动 过 程 。 


9.3 ”Service 的 工作 过 程 


在 9.2 节 中 介绍 了 Activity 的 工作 过 程 ， 本 市 将 介绍 Service 的 工作 过 
程 ， 通 过 本 节 的 分 析 ， 读 者 将 会 对 Service 的 一 些 工作 原理 有 更 进一步 的 
认识 ， 比 如 Service 的 启动 过 程 和 绑 定 过 程 。 在 分 析 Service 的 工作 过 程 之 
前 ， 先 看 一 下 如 何 使 用 一 个 Service。Service 分 为 两 种 工作 状态 ， 一 种 是 
启动 状态 ， 主 要 用 于 执行 后 台 计 算 ; 另 一 种 是 绑 定 状态 ， 主 要 用 于 其 他 
组 件 和 Service 的 交互 。 需 要 注意 的 是 ， Se APRA 是 可 以 共存 
的 ， 即 Service 既 可 以 处 于 启动 状态 也 可 以 同时 处 于 绑 定 状态 。 通 过 
Context 的 startService 方 法 即 可 启动 一 个 Service， 如 下 所 示 。 








Intent intentService = new Intent(this,MyService.class); 


startService(intentService); 





通过 Context 的 bindService 方 法 即 可 以 绑 定 的 方式 局 动 一 个 Service， 
如 下 所 示 。 


Intent intentService = new Intent(this,MyService.class); 


bindService(intentService, mServiceConnection, BIND_AUTO_CREATE 


9.3.1 Service 的 局 动 过 程 


Service 的 启动 过 程 从 ContextWrapper 的 startActivity 开 始 ， 如 下 所 


public ComponentName startService(Intent service) { 


return mBase.startService(service); 


上 面 代码 的 mBase 的 类 型 是 ContextImpl， 在 9.2 节 中 我 们 知道 ， 
Activity 被 创建 时 会 通过 attach 方 法 将 一 个 ContextImpl 对 象 关联 起 来 ， 
个 ContextImpl 对 象 就 是 上 述 代码 中 的 mBase。 从 ContextWrapper 的 实现 
可 以 看 出 ， 其 大 部 分 操作 都 是 通过 mBase 来 实现 的 ， 在 设计 模式 中 这 是 
一 种 典型 的 桥接 模式 。 下 面 继续 看 ContextImpl 的 startActivity 的 实现 ， 如 
下 所 示 。 


public ComponentName startService(Intent service) { 
warnIfCallingFromSystemProcess(); 
return startServiceCommon(service, mUser ) ; 

} 

private ComponentName startServiceCommon(Intent service,UserH 
try { 

validateServiceIntent(service); 

service.prepareToLeaveProcess(); 

ComponentName cn = ActivityManagerNative.getDefau 
mMainThread.getApplicationThread(),servic 
service.resolveTypeIfNeeded(getContentRes 

if (cn != null) { 
if (cn.getPackageName().equals("!")) { 

throw new SecurityException( 
"Not allowed to s 
+ " without permi 


} else if (cn.getPackageName().equals("!! 


throw new SecurityException( 
"Unable to start 


eS eC. ete 


} 


return cn; 
} catch (RemoteException e) { 


return null; 


在 ContextImpl 中 ，startService 方 法 会 调用 startServiceCommon 方 
法 ， 而 startService-Common 方 法 又 会 通过 
ActivityManagerNative.getDefaultO 这 个 对 象 来 司 动 一 个 服务 。 对 于 
ActivityManagerNative.getDefault() 这 个 对 象 ， 我 们 应 该 有 点 印象 ， 在 9.2 
人 
AMS (ActivityManagerService) ， 这 里 就 不 再 重复 说 明了 。 需 要 注意 的 
是 ， 在 上 述 代码 中 通过 AMS 来 启 ee 行为 是 一 个 远程 过 程 调 用 。 
AMS 的 startService 方 法 的 实现 如 下 所 示 。 





public ComponentName startService(IApplicationThread caller,I 
String resolvedType,int userId) { 
enforceNotIsolatedCaller("startService"); 
// Refuse possible leaked file descriptors 
if (service != null && service.hasFileDescriptors() == tr 


throw new IllegalArgumentException("File descript 


if (DEBUG_SERVICE) 
Slog.v(TAG,""startService: " + service + " type=" 

synchronized(this) { 
final int callingPid = Binder.getCallingPid(); 
final int callingUid = Binder.getCallingUid(); 
final long origId = Binder.clearCallingIdentity( ) 
ComponentName res = mServices.startServiceLocked( 

resolvedType, callingPid, callingUi 

Binder .restoreCallingIdentity(origId); 


return res; 


在 上 面 的 代码 中 ，AMS 会 通过 mServices 这 个 对 象 来 完成 Service 后 
续 的 启动 过 程 ，mServices 对 象 的 类 型 是 ActiveServices，ActiveServices 
是 一 个 辅助 AMS 进 行 Service 管 理 的 类 ， 包 括 Service 的 启动 、 绑 定 和 停止 
等 。 在 ActiveServices 的 startServiceLocked 方 法 的 尾部 会 调用 
startServiceInnerLocked 方 法 ，startServiceInnerLocked 的 实现 如 下 所 示 。 





ComponentName startServiceInnerLocked(ServiceMap smap, Intent 

ServiceRecord r,boolean callerFg, boolean addToSta 

ProcessStats.ServiceState stracker = r.getTracker(); 

if (stracker != null) { 
stracker.setStarted(true,mAm.mProcessStats.getMem 

} 

r.callStart = false; 

synchronized (r.stats.getBatteryStats()) { 


在 上 述 代 人 码 中 ，ServiceRecord 描 述 的 是 一 个 Service 记 录 ， 
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startServiceInnerLocked 方 法 并 没有 完成 具体 的 启动 工作 ， 而 是 把 后 续 的 
工作 交 给 了 bringUpServiceLocked 方 法 来 处 理 ， 在 bringUpServiceLocked 
方法 中 又 调用 了 realStartServiceLocked 方 法 。 从 名 字 上 来 看 ， 这 个 方法 
应 该 是 真正 地 启动 一 个 Service， 它 的 实现 如 下 所 示 。 


private final void realStartServiceLocked(ServiceRecord r, 


ProcessRecord app,boolean execInFg) throws Remote 


boolean created = false; 


try { 


String nameTerm; 
int lastPeriod = r.shortName.lastIndexOf('.'); 
nameTerm = lastPeriod => 0 ? r.shortName.substrin 
if (LOG_SERVICE_START_STOP) { 
EventLogTags.writeAmCreateService( 
r.useriId, System. identityH 
} 
synchronized (r.stats.getBatteryStats()) { 
r.stats.startLaunchedLocked(); 
} 
mAm.ensurePackageDexOpt(r.serviceInfo.packageName 
app.forceProcessStateUpTo(ActivityManager .PROCESS 
app.thread.scheduleCreateService(r,r.servicelInfo, 
mAm.compatibilityInfoForPackageLo 
app.repProcState); 


r.postNotification(); 


在 realStartServiceLocked 方 法 中 ， 首 先 通过 app.thread 的 
scheduleCreateService 方 法 来 创建 Service 对 象 并 调用 其 onCreate， 接 着 再 





通过 sendServiceArgsLocked 方 法 来 调用 Service 的 其 他 方法 ， 比 如 
onStartCommand， 这 两 个 过 程 均 是 进程 间 通 信 。app.thread 对 象 是 
IApplicationThread 类 型 ， 它 实际 上 是 一 个 Binder， 它 的 具体 实现 是 
ApplicationThread 和 ApplicationThreadNative， 在 9.2 节 已 经 对 这 个 问题 做 
了 说 明 。 由 于 ApplicationThread 继 承 了 ApplicationThreadNative， 因 此 只 
需要 看 ApplicationThread 对 Service 启 动 过 程 的 处 理 即 可 ， 这 对 应 着 它 的 
scheduleCreateService 方 法 ， 如 下 所 示 。 














public final void scheduleCreateService(IBinder token, 
ServiceInfo info,CompatibilityInfo compatInfo, int 
updateProcessState(processState, false); 
CreateServiceData s = new CreateServiceData(); 
s.token = token; 
s.info = info; 
s.compatiInfo = compatInfo; 


sendMessage(H.CREATE_SERVICE,s)j; 


很 显然 ， 这 个 过 程 和 Activity 的 启动 过 程 是 类 似 的 ， 都 是 通过 发 送 
消息 给 Handler 日 来 完成 的 。H 会 接收 这 个 CREATE_SERVICE 消 息 并 通 
过 ActivityThread 的 handleCreateService 方 法 来 完成 Service 的 最 终 启 动 ， 
handleCreateService 的 源码 如 下 所 示 。 


private void handleCreateService(CreateServiceData data) { 
// If we are getting ready to gc after going to the backg 
// we are back active so skip it. 
unscheduleGcIdler(); 


LoadedApk packageInfo = getPackageInfoNoCheck( 





} catch (Exception e) { 
if (!mInstrumentation.onException(service,e)) { 
throw new RuntimeException( 
"Unable to create service " + dat 


+": " + e,toString(),e); 





handleCreateService 主 要 完成 了 如 下 几 件 事 。 
首先 通过 类 加 载 器 创建 Service 的 实例 。 


然后 创建 Application 对 象 并 调用 其 onCreate， 当 然 Application 的 创建 
过 程 只 会 有 一 次 。 


接着 创建 ConTextImpl 对 象 并 通过 Service 的 attach 方 法 建立 二 者 之 间 
的 关系 ， 这 个 过 程 和 Activity 实 际 上 是 类 似 的 ， 毕 竟 Service 和 Activity 都 


是 一 个 Context。 


最 后 调用 Service 的 onCreate 方 法 并 将 Service 对 象 存储 到 
ActivityThread 中 的 一 个 列表 中 。 这 个 列表 的 定义 如 下 所 示 。 


final ArrayMap<IBinder,Service> mServices = new ArrayMap<IBinder, 


由 于 Service 的 onCreate 方 法 被 执行 了 ， 这 也 意味 着 Service 已 经 局 动 
了 。 除 此 之 外 ，ActivityThread 中 还 会 通过 handleServiceArgs 方 法 调用 
Service 的 onStartCommand 方 法 ， 如 下 所 示 。 


private void handleServiceArgs(ServiceArgsData data) { 





到 这 里 ，Service 的 启动 过 程 已 经 分 析 完 了 ， 下 面 分 析 Service 的 绑 定 


9.3.2 Service 的 绑 定 过 程 


和 Service 的 启动 过 程 一 样 ，Service 的 绑 定 过 程 也 是 从 
ContextWrapper 开 始 的 ， 如 下 所 示 。 


public boolean bindService(Intent service, ServiceConnection c 
int flags) { 


return mBase.bindService(service, conn, flags); 


这 个 过 程 和 Service 的 启动 过 程 是 类 似 的 ，mBase 同 样 是 ContextImpl 
类 型 的 对 象 。ContextImpl 的 bindService 方 法 最 终 会 调用 自己 的 
bindServiceCommon 方 法 ， 如 下 所 示 。 


private boolean bindServiceCommon(Intent service, ServiceConne 
UserHandle user) { 
IServiceConnection sd; 
if (conn == null) { 


throw new IllegalArgumentException("connection is 





bindServiceCommon 方 法 主要 完成 如 下 两 件 事情 。 


首先 将 客户 端的 ServiceConnection 对 象 转化 为 
ServiceDispatcher.InnerConnection 对 象 。 之 所 以 不 能 直接 使 用 
ServiceConnection 对 象 ， 这 是 因为 服务 的 绑 定 有 可 能 是 路 进程 的 ， 因 此 
ServiceConnection 对 象 必须 借助 于 Binder 才 能 让 远程 服务 端 回调 自己 的 
方法 ， 而 ServiceDispatcher 的 内 部 类 InnerConnection 刚 好 充当 了 Binder 这 
个 角色 。 那 么 ServiceDispatcher 的 作用 是 什么 呢 ? 其 实 ServiceDispatcher 
起 着 连接 ServiceConnection 和 InnerConnection 的 作用 。 这 个 过 程 由 
LoadedApk 的 getServiceDispatcher 方 法 来 完成 ， 它 的 实现 如 下 : 








public final IServiceConnection getServiceDispatcher (ServiceC 
Context context,Handler handler,int flags) { 
synchronized (mServices) { 
LoadedApk.ServiceDispatcher sd = null; 
ArrayMap<serviceConnection, LoadedApk.ServiceDispa 
if (map != null) { 
sd = map.get(c); 
Í 
if (sd == null) 4 
sd = new ServiceDispatcher(c, context, hand 
if (map == null) { 
map = new ArrayMap<serviceConnect 


mServices.put(context,map); 


map.put(c,sd); 
} else { 
sd.validate(context, handler); 


} 


return sd.getIServiceConnection(); 


在 上 面 的 代码 中 ，mServices 是 一 个 ArrayMap， 它 存储 了 一 个 应 用 
当前 活动 的 ServiceConnection 和 ServiceDispatcher 的 映射 关系 ， 它 的 定义 
如 下 所 示 。 


private final ArrayMap<Context,ArrayMap<serviceConnection,Loa 








系统 首先 会 查找 是 否 存在 相同 的 ServiceConnection， 如 果 不 存 在 就 
重新 创建 一 个 ServiceDispatcher 对 象 并 将 其 存储 在 mServices 中 ， 其 中 映 
射 关 系 的 key 是 ServiceConnection，value 是 ServiceDispatcher， 在 
ServiceDispatcher 的 内 部 又 保存 了 ServiceConnection 和 InnerConnection 对 
象 。 当 Service 和 客 己 端 建立 连接 后 ， 系 统 会 通过 InnerConnection 来 调用 
ServiceConnection 中 的 onServiceConnected 方 法 ， 这 个 过 程 有 可 能 是 跨 进 
程 的 。 当 ServiceDispatcher 创 建 好 了 以 后 ，getServiceDispatcher 会 返回 其 
保存 的 InnerConnection 对 象 。 


接着 bindServiceCommon 方 法 会 通过 AMS 来 完成 Service 的 有 具体 的 绑 
定 过 程 ， 这 对 应 于 AMS 的 bindService 方 法 ， 如 下 所 示 。 


public int bindService(IApplicationThread caller,IBinder toke 


Intent service,String resolvedType, 


IServiceConnection connection,int flags,int userI 
enforceNotIsolatedCaller("bindService"); 
// Refuse possible leaked file descriptors 
if (service != null && service.hasFileDescriptors() == tr 
throw new IllegalArgumentException("File descript 
} 
synchronized(this) { 
return mServices.bindServiceLocked(caller,token,s 


connection, flags, userId); 


接 下 来 ，AMS 会 调用 ActiveServices 的 bindServiceLocked 方 法 ， 
bindServiceLocked 再 调用 bringUpServiceLocked，bringUpServiceLocked 
又 会 调用 realStartServiceLocked 方 法 ，realStartServiceLocked 方 法 的 执行 
逻辑 和 9.3.1 节 中 的 逻辑 类 似 ， 最 终 都 是 通过 ApplicationThread 来 完成 
Service 实 例 的 创建 并 执行 其 onCreate 方 法 ， 这 里 不 再 重复 讲解 了 。 和 局 
动 Service 不 同 的 是 ，Service 的 绑 定 过 程 会 调用 app.thread 的 
scheduleBindService 方 法 ， 这 个 过 程 的 实现 在 ActiveServices 的 
requestServiceBindingLocked 方 法 中 ， 如 下 所 示 。 


private final boolean requestServiceBindingLocked(ServiceReco 
IntentBindRecord i,boolean execInFg,boolean rebin 
if (r.app == null || r.app.thread == null) { 
// If service is not currently running,can't yet 


return false; 


在 上 述 代码 中 ，app.thread 这 个 对 象 多 次 出 现 过 ， 对 于 它 我 们 应 该 再 
熟悉 不 过 了 ， 它 实际 上 就 是 ApplicationThread。ApplicationThread 的 一 系 
列 以 schedule 开 头 的 方法 ， 其 内 部 都 是 通过 Handler HRPP, XF 
scheduleBindService 方 法 来 说 也 是 如 此 ， 它 的 实现 如 下 所 示 。 





BindServiceData s = new BindServiceData()j; 
s.token = token; 
s.intent = intent; 
s.rebind = rebind; 
if (DEBUG_SERVICE) 
Slog.v(TAG, "scheduleBindService token=" + token + 
+ Binder.getCallingUid() + " pid= 


sendMessage(H.BIND_SERVICE,Ss); 





在 HH 内部， 接收 到 BIND_SERVICE 这 类 消息 时 ， 会 交 给 
ActivityThread 的 handleBind-Service 方 法 来 处 理 。 在 handleBindService 
中 ， 首 先 根 据 Service 的 token 取 出 Service 对 象 ， 然 后 调用 Service 的 onBind 
方法 ，Service 的 onBind 方 法 会 返回 一 个 Binder 对 象 给 客户 端 使 用 ， 这 个 
过 程 我 们 在 Service 的 开发 过 程 中 应 该 都 比较 熟 秋 了。 原则 上 来 说 ， 
Service 的 onBind 方 法 被 调用 以 后 ，Service 就 处 于 绑 定 状态 了 ， 但 是 
onBind 方 法 是 Service 的 方法 ， 这 个 时 候 客户 问 并 不 知道 已 经 成 功 连接 
Service 『 了 ， 所 以 还 必须 调用 客户 端的 ServiceConnection 中 的 
onServiceConnected， 这 个 过 程 是 由 ActivityManagerNative.getDefault() 的 
publishService 方 法 来 完成 的 ， 而 前 面 多 次 提 到 ， 
ActivityManagerNative.getDefaultO 就 是 AMS 。handleBindService 的 实现 
过 程 如 下 所 示 。 





private void handleBindService(BindServiceData data) { 
Service s = mServices.get(data.token); 
if (DEBUG_SERVICE) 


Slog.v(TAG, "handleBindService s=" + s + " rebind= 





Service 有 一 个 特性 ， 当 多 次 绑 定 同一 个 Service 时 ，Service 的 onBind 
方法 只 会 执行 一 次 ， 除 非 Service 被 终止 了 。 当 Service 的 onBind 执 行 以 
后 ， 系 统 还 需要 告知 客户 端 已 经 成 功 连接 Service 了 。 根 据 上 面 的 分 析 ， 
这 个 过 程 由 AMS 的 publishService 方 法 来 实现 ， 它 的 源码 如 下 所 示 。 





public void publishService(IBinder token, Intent intent, IBinde 
// Refuse possible leaked file descriptors 
if (intent != null && intent.hasFileDescriptors() == true 
throw new IllegalArgumentException("File descript 
J 
synchronized(this) { 
if (!(token instanceof ServiceRecord)) { 
throw new IllegalArgumentException("Inval 


} 


mServices.publishServiceLocked((ServiceRecord)tok 


从 上 面 代码 可 以 看 出 ，AMS 的 publishService 方 法 将 具体 的 工作 交 给 
了 ActiveServices 类 型 的 mServices 对 象 来 处 理 。ActiveServices 的 
publishServiceLocked 方 法 看 起 来 很 复杂 ， 但 其 实 核心 代码 就 只 有 一 句 


tH: c.conn.connected(r.name,service)， 其 中 c 的 类 型 是 








ConnectionRecord，c.comn 的 类 型 是 ServiceDispatcher.InnerConnection， 
service ize ServicelonBind 77 KR [A] BinderX R. A T a tr AAA 
辑 ， 下 面 看 一 下 ServiceDispatcher. InnerConnection 的 定义 ， 如 下 所 示 。 


private static class InnerConnection extends IServiceConnecti 


final WeakReference<LoadedApk.ServiceDispatcher> mDispatc 


InnerConnection(LoadedApk.ServiceDispatcher sd) { 
mDispatcher = new WeakReference<LoadedApk.Service 

Í 

public void connected(ComponentName name, IBinder service) 
LoadedApk.ServiceDispatcher sd = mDispatcher.get( 
if (sd != null) { 


sd.connected(name, service); 


从 InnerConnection 的 定义 可 以 看 出 ， 它 的 connected 方 法 又 调用 了 
ServiceDispatcher 的 connected 方 法 ，ServiceDispatcher 的 connected 方 法 的 
实现 如 下 所 示 。 


public void connected(ComponentName name, IBinder service) { 
if (mActivityThread != null) { 
mActivityThread.post(new RunConnection(name, servi 
} else { 


doConnected(name, service); 


对 于 Service 的 绑 定 过 程 来 说 ，ServiceDispatcher 的 mActivityThread 
是 一 个 Handler， 其 实 它 就 是 ActivityThread 中 的 H， 从 前 面 
ServiceDispatcher 的 创建 过 程 来 说 ，mActivityThread 不 会 为 null， 这 样 一 
来 ，RunConnection 就 可 以 经 由 瑞 的 post 方 法 从 而 运行 在 主线 程 中 ， 
此 ， 客 户 端 ServiceConnection 中 的 方法 是 在 主线 程 被 回调 的 。 





RunConnection 的 定义 如 下 所 示 。 





很 显然 ，RunConnection 的 run 方 法 也 是 简单 调用 了 ServiceDispatcher 
的 doConnected 方 法 ， 由 于 ServiceDispatcher 内 部 保存 了 客户 端的 
ServiceConnection 对 象 ， 因 此 它 可 以 很 方便 地 调用 ServiceConnection 对 
象 的 onServiceConnected 方 法 ， 如 下 所 示 。 





} 


客户 端的 onServiceConnected 方 法 执行 后 ，Service 的 绑 定 过 程 也 就 
分 析 完 成 了 ， 至 于 Service 的 停止 过 程 和 解除 绑 定 的 过 程 ， 系 统 的 执行 过 
程 是 类 似 的 ， 读 者 可 以 自行 分 析 源 人 码 ， 这 里 就 不 再 分 析 了 。 


9.4 ”BroadcastReceiver 的 工作 过 程 


本 贡 将 介绍 BroadcastReceiver 的 工作 过 程 ， 主 要 包含 两 方面 的 内 
容 ， 一 个 是 广播 的 注册 过 程 ， 另 一 个 是 广播 的 发 送 和 接收 过 程 。 这 里 先 
简单 回顾 一 下 广播 的 使 用 方法 ， 首 先 要 定义 广播 接收 者 ， 只 需要 继承 
a onReceive 方 法 即 可 ， 下 面 是 一 个 典型 的 广播 接 
收 者 的 实现 ; 


public class MyReceiver extends BroadcastReceiver { 
@Override 
public void onReceive(Context context,Intent intent) { 
// onReceive 函 数 不 能 做 耗 时 的 事情 ， 参 考 值 : 10s 以 内 
Log.d("scott","on receive action=" + intent.getActio 
String action = intent.getAction(); 


// do some works 


} 


定义 好 了 广播 接收 者 ， 接 着 还 需要 注册 广播 接收 者 ， 注 册 分 为 两 种 
方式 ， 既 可 以 在 AndroidManifest 文 件 中 静态 注册 ， 也 可 以 通过 代码 动态 
注册 。 

静态 注册 的 示例 如 下 : 


<receiver android:name=".MyReceiver" > 


<intent-filter> 


<action android:name="com.ryg.receiver.LAUNCH" /> 
</intent-filter> 


</receiver> 





通过 代码 来 动态 注册 广播 也 是 很 简单 的 ， 如 下 所 示 。 需 要 注意 的 
是 ， 动 态 注册 的 广播 需要 在 合适 的 时 机 进行 解 注 册 ， 解 注册 采用 
unregisterReceiver 方 法 。 

IntentFilter filter = new IntentFilter(); 


filter.addAction("com.ryg.receiver.LAUNCH") ; 


registerReceiver(new MyReceiver(), filter); 





前 面 两 步 都 完成 了 以 后 ， 就 可 以 通过 send 方 法 来 用 送 广播 了 ， 如 下 
所 示 。 


Intent intent = new Intent(); 
intent.setAction("com.ryg.receiver.LAUNCH") ; 


sendBroadcast(intent); 


上 面 简单 回顾 了 广播 的 使 用 方法 ， 下 面 就 开始 分 析 广 播 的 工作 过 
程 ， 首 移 分 析 广 播 的 注册 过 程 ， 接 着 再 分 析 广 播 的 发 送 和 接收 过 程 。 


9.4.1 广播 的 注册 过 程 


广播 的 注册 分 为 静态 注册 和 动态 注册 ， 其 中 静态 注册 的 广播 在 应 用 
安装 时 由 系统 自动 完成 注册 ， 具 体 来 说 是 由 
PMS (PackageManagerService) 来 完成 整个 注册 过 程 的 ， 除 了 广播 以 
外 ， 其 他 三 大 组 件 也 都 是 在 应 用 安 疤 时 由 PMS 解 析 并 注册 的 。 这 里 只 分 


析 广 播 的 动态 注册 的 过 程 ， 动 态 注册 的 过 程 是 从 ContextWrapper 的 
registerReceiver 方 法 开始 的 ， 和 Activity 以 及 Service 一 样 。 
ContextWrapper 并 没有 做 实际 的 工作 ， 而 是 将 注册 过 程 直接 交 给 了 
ContextImpl] 来 完成 ， 如 下 所 示 。 


public Intent registerReceiver ( 
BroadcastReceiver receiver,IntentFilter filter) { 


return mBase.registerReceiver(receiver, filter); 


ContextImpl 的 registerReceiver 方 法 调用 了 自己 的 
registerReceiverInternal 方 法 ， 它 的 实现 如 下 所 示 。 





private Intent registerReceiverInternal(BroadcastReceiver rec 
IntentFilter filter,String broadcastPermission, 
Handler scheduler,Context context) { 
IIntentReceiver rd = null; 
if (receiver != null) { 
if (mPackageInfo != null && context != null) { 
if (scheduler == null) { 
scheduler = mMainThread.getHandle 
} 
rd = mPackageInfo.getReceiverDispatcher( 
receiver, context, scheduler, 
mMainThread.getInstrumentation(), 
} else { 
if (scheduler == null) { 


scheduler = mMainThread.getHandle 


象 ， 


} 


rd = new LoadedApk.ReceiverDispatcher ( 


receiver, context, schedule 


try { 


return ActivityManagerNative.getDefault().registe 
mMainThread. getApplicationThread( 
rd, filter, broadcastPermission, use 

} catch (RemoteException e) { 


return null; 


在 上 面 的 代码 中 ， 系 统 首先 从 mPackageInfo 获 取 IIntentReceiver 对 
然后 再 采用 跨 进程 的 方式 同 AMS 发 送 广 播 注册 的 请 求 。 之 所 以 采用 


IIntentReceiver 而 个 是 直接 采用 BroadcastReceiver， 这 是 因为 上 述 注册 过 


早 是 一 个 进程 间 通 信和 的 过 程 ， 而 BroadcastReceiver 作 为 Android 的 一 个 组 


件 是 不 能 直接 跨 进 程 传递 的 ， 所 以 需要 通过 IIntentReceiver 来 中 转 一 





Fo 





毫 无 疑问 ，IIntentReceiver 必 须 是 一 个 Binder 接 口 ， 它 的 具体 实现 是 


LoadedApk.Receiver-Dispatcher.InnerReceiver，ReceiverDispatcher 的 内 部 
同时 保存 了 BroadcastReceiver 和 InnerReceiver， 这 样 当 接收 到 广播 时 ， 
ReceiverDispatcher 可 以 很 方便 地 调用 BroadcastReceiver 的 onReceive 方 
法 ， 有 具体 会 在 9.4.2 节 中 说 明 。 可 以 发 现 ，BroadcastReceiver 的 这 个 过 程 
和 Service 的 实现 原理 类 似 ，Service 也 有 一 个 叫 ServiceDispatcher 的 类 
rd rt ee ta gt 作用 同样 也 是 为 了 
进程 间 通 信 ， 这 一 点 在 9.3.2 节 中 已 经 摘 述 过 了 ， 这 里 不 再 重复 说 明 。 


关于 ActivityManagerNative.getDefault()， 这 里 就 不 用 再 做 说 明了 ， 
它 就 是 AMS， 在 前 面 的 章节 中 已 经 多 次 提 到 它 。 下 面 看 一 下 
ReceiverDispatcher 的 getIIntentReceiver 的 实现 ， 如 下 所 示 。 很 显然 ， 
getReceiverDispatcher 方 法 重新 创建 了 一 个 ReceiverDispatcher 对 象 并 将 其 
保存 的 InnerReceiver 对 象 作为 返回 值 返回 ， 其 中 InnerReceiver 对 象 和 
BroadcastReceiver 都 是 在 ReceiverDispatcher 的 构造 方法 中 被 保存 起 来 


的 。 


public IIntentReceiver getReceiverDispatcher (BroadcastReceive 





Context context,Handler handler, 


Instrumentation instrumentation, boolean registere 


synchronized (mReceivers) { 
LoadedApk.ReceiverDispatcher rd = null; 
ArrayMap<BroadcastReceiver, LoadedApk.ReceiverDisp 
if (registered) { 
map = mReceivers.get(context); 
if (map != null) { 
rd = map.get(r); 


} 
if (rd == null) 4 
rd = new ReceiverDispatcher(r,context, han 
instrumentation, registere 
if (registered) { 
if (map == null) { 
map = new ArrayMap<Broadc 


mReceivers.put(context,ma 


由 于 注册 广播 的 真正 实现 过 程 是 在 AMS 中 ， 因 此 我 们 需要 看 一 下 
AMS 的 具体 实现 。AMS 的 registerReceiver 方 法 看 起 来 很 长 ， 其 实 关键 点 
就 只 有 下 面 一 部 分 ， 最 终 会 把 远程 的 InnerReceiver 对 象 以 及 IntentFilter 对 


象 存储 起 来 ， 这 样 整个 广播 的 注册 过 程 就 完成 了 ， 代 码 如 下 所 示 。 





9.4.2 J HEY AIK A UC FE 


上 面 分 析 了 广播 的 注册 过 程 ， 可 以 发 现 注 册 过 程 的 逻辑 还 是 比较 简 
单 的 ， 下 面 来 分 析 广 播 的 发 送 和 接收 过 程 。 当 通过 send 方 法 来 肥 送 广播 
时 ，AMS 会 但 找 出 匹配 的 广播 接收 者 并 将 广播 肥 送 给 它们 处 理 。 广 播 的 
发 送 有 几 种 类 型 ， 普 通 广 播 、 有 厅 广 播 和 粘性 广播 ， 有 订 广 播 和 粘性 广 
播 与 普通 广播 相 比 具有 不 同 的 特性 ， 但 是 它们 的 发 送 /接收 过 程 的 流程 
古 类 似 的 ， 因 此 这 里 只 分 析 普 通 广 播 的 实现 。 








广播 的 发 送 和 接收 ， 其 本 质 是 一 个 过 程 的 两 个 阶段 。 这 里 从 广播 的 
发 送 可 以 说 起 ， 广 播 的 发 送 仍然 开始 于 ContextWrapper 的 sendBroadcast 
方法 ， 之 所 以 不 是 Context， 那 是 因为 Context 的 sendBroadcast 是 一 个 抽象 
方法 。 和 广播 的 注册 过 程 一 样 ，ContextWrapper 的 sendBroadcast 方 法 仍 
然 什么 都 不 做 ， 只 是 把 事情 交 给 ContextImpl 去 处 理 ，ContextImpl 的 
sendBroadcast 方 法 的 源码 如 下 所 示 。 


public void sendBroadcast(Intent intent) { 
warnIfCallingFromSystemProcess(); 
String resolvedType = intent.resolveTypeIfNeeded(getConte 
try { 
intent.prepareToLeaveProcess(); 
ActivityManagerNative.getDefault().broadcastInten 
mMainThread.getApplicationThread(),intent 
Activity.RESULT_OK, null, null,null, AppOpsM 


getUserlId()); 
} catch (RemoteException e) { 


} 


从 上 面 的 代码 来 看 ，ContextImpl 也 是 几乎 什么 事 都 没 干 ， 它 直接 问 
AMS 发 起 了 一 个 异步 请 求 用 于 发 送 广播 。 因 此 ， 下 面 直接 看 AMS 对 广 
播发 送 过 程 的 处 理 ，AMS 的 broadcastIntent 方 法 的 源码 如 下 所 示 。 





public final int broadcastIntent(IApplicationThread caller, 
Intent intent,String resolvedType, IIntentReceiver 
int resultCode,String resultData, Bundle map, 
String requiredPermission, int appOp,boolean seria 
enforceNotIsolatedCaller("broadcastIntent"); 
synchronized(this) { 
intent = verifyBroadcastLocked(intent); 
final ProcessRecord callerApp = getRecordForAppLo 
final int callingPid = Binder.getCallingPid(); 
final int callingUid = Binder.getCallingUid(); 
final long origId = Binder.clearCallingIdentity( ) 
int res = broadcastIntentLocked(callerApp, 
callerApp != null ? callerApp. inf 
intent, resolvedType, resultTo, 
resultCode, resultData, map, require 
callingPid, callingUid, userId); 
Binder .restoreCallingIdentity(origId); 


return res; 


} 


从 上 面 代 码 来 看 ，broadcastIntent 调 用 了 broadcastIntentLocked 方 
法 ，AMS 的 broadcastIntentLocked 方 法 有 436 行 代码 ， 看 起 来 比较 复杂 。 
在 代码 最 开始 有 如 下 一 行 


// By default broadcasts do not go to stopped apps. 
intent .addFlags(Intent .FLAG_EXCLUDE_STOPPED_PACKAGES) ; 





这 表示 在 Android 5.0 中 ， 默 认 情 况 下 广播 不 会 发 送 给 已 经 停止 的 应 
用 ， 其 实 不 仅仅 是 Android 5.0， 从 Android 3.1 开 始 广 播 已 经 具有 这 种 特 
性 了 。 这 是 因为 系统 在 Android 3.1 中 为 Intent 湛 加 了 两 个 标记 位 ， 分 别 是 
FLAG _INCLUDE_STOPPED_PACKAGES fil 
FLAG_EXCLUDE_STOPPED_PACKAGES， 用 来 控制 广播 是 否 要 对 处 
于 停止 状态 的 应 用 起 作用 ， 它 们 的 含义 如 下 所 示 。 


-> 





er ad 


FLAG_INCLUDE_STOPPED_PACKAGES 


表示 包含 已 经 停止 的 应 用 ， 这 个 时 候 广播 会 发 送 给 已 经 停止 的 应 
用 。 


FLAG_EXCLUDE_STOPPED_PACKAGES 


表示 不 包含 已 经 停止 的 应 用 ， 这 个 时 候 广播 不 会 发 送 给 已 经 停止 的 
应 用 。 


从 Android 3.1 开 始 ， 系 统 为 所 有 广播 默认 添加 了 
FLAG_EXCLUDE_STOPPED_PACKAGES 标 志 ， 这 e 
播 无 意 间或 者 在 不 必要 的 时 候 调 起 已 经 停止 运行 的 应 用 。 如 果 的 确 需 





调 起 未 启动 的 应 用 ， 那 么 只 需要 为 广播 的 Intent 添 加 
FLAG_INCLUDE_STOPPED_ PACKAGES 标 记 即 可 。 当 

FLAG _EXCLUDE_STOPPED_PACKAGES fil 
FLAG_INCLUDE_STOPPED_PACKAGES 两 种 标记 位 共存 时 ， 

FLAG INCLUDE_STOPPED RACE 这 里 需要 补充 一 下 

个 应 用 处 于 停止 状态 分 为 两 种 情形 : 第 一 种 是 应 用 安装 后 未 运行 ， 第 二 
种 是 应 用 被 手动 或 者 其 他 应 用 强 停 了 。 ee 
样 会 影响 开机 广播 ， 从 Android 3.1 开 始 ， 处 于 停止 状态 的 应 用 同样 无 法 
接收 到 开机 广播 ， 而 在 Android 3.1 之 前 ， 处 于 停止 状态 的 应 用 是 可 以 收 
到 开机 广播 的 。 








在 broadcastIntentLocked 的 内 部 ， 会 根据 intent-filter 碍 找 出 匹配 的 广 
播 接收 者 并 经 过 一 系列 的 条 件 过 滤 ， 最 终 会 将 满足 条 件 的 广播 接收 者 添 
加 了 中 ， 接 着 BroadcastQueue 就 会 将 广播 发 送 给 相应 的 
广播 接收 者 ， 这 个 过 程 的 源码 如 下 所 示 。 


if ((receivers != null && receivers.size() > 0) 
|| resultTo != null) { 
BroadcastQueue queue = broadcastQueueForiIntent(intent ); 
BroadcastRecord r = new BroadcastRecord( queue, intent, call 
callerPackage, callingPid, callingUid, resol 
requiredPermission, appOp, receivers, result 
resultData, map, ordered, sticky, false, userI 
if (DEBUG_BROADCAST) Slog.v( 
TAG, "Enqueueing ordered broadcast " + r 
+ ": prev had " + queue.mOrderedBroadcasts.size()); 


if (DEBUG_BROADCAST) { 


int seq = r.intent.getIntExtra("seq", -1); 

Slog.i(TAG, "Enqueueing broadcast " + r.intent.get. 
Í 
boolean replaced = replacePending && queue.replaceOrdered 
if (!replaced) { 

queue .enqueueOrderedBroadcastLocked(r); 


queue .scheduleBroadcastsLocked(); 


下 面 看 一 下 BroadcastQueue 中 广播 的 发 送 过 程 的 实现 ， 如 下 所 示 。 


public void scheduleBroadcastsLocked() { 
if (DEBUG_BROADCAST) Slog.v(TAG, "Schedule broadcasts [" 
+ mQueueName + "]: current=" 
+ mBroadcastsScheduled) ; 
if (mBroadcastsScheduled) { 
return; 
| 
mHandler .sendMessage(mHandler .obtainMessage(BROADCAST_INT 


mBroadcastsScheduled = true; 


BroadcastQueue 的 scheduleBroadcastsLocked 方 法 并 没有 立即 发 送 广 
播 ， 而 是 发 送 了 一 个 BROADCAST_INTENT_MSG 类 型 的 消息 ， 
BroadcastQueue 收 到 消息 后 会 调用 process-NextBroadcast 方 法 ， 
BroadcastQueue 的 processNextBroadcast 方 法 对 普通 广播 的 处 理 如 下 所 
ANS 








// First,deliver any non-serialized broadcasts right away. 
while (mParallelBroadcasts.size() > 0) { 
r = mParallelBroadcasts.remove(0O); 
r.dispatchTime = SystemClock.uptimeMillis(); 
r.dispatchClockTime = System.currentTimeMillis(); 
final int N = r.receivers.size(); 
if (DEBUG_BROADCAST_LIGHT) Slog.v(TAG, "Processing paralle 
+ mQueueName + "| "+ r); 
for (int i=0; i<N; i++) { 
Object target = r.receivers.get(i); 
if (DEBUG_BROADCAST) Slog.v(TAG, 
"Delivering non-ordered on["+mQueueName + 
+ target +": " +r); 
deliverToRegisteredReceiverLocked(r, (BroadcastFil 
J 
addBroadcastToHistoryLocked(r); 
if (DEBUG_BROADCAST_LIGHT) Slog.v(TAG, "Done with parallel 


+ mQueueName + "] "+ r); 





HAE, LF i EmParalelBroadcasts t, Ase iki 
eral ead e 中 的 广播 发 送 给 它们 所 有 的 接收 者 ， 具 体 的 
发 送 过 程 是 通过 deliverToRegistered-ReceiverLocked 方 法 来 实现 的 。 
deliverToRegisteredReceiverLocked 方 法 负责 将 一 个 广播 发 送 给 一 个 特 冠 
的 接收 者 ， 它 内 部 调用 了 performReceiveLocked 方 法 来 完成 具体 的 发 送 
过 程 : 








performReceiveLocked(filter.receiverList.app, filter.receiverL 
new Intent(r.intent),r.resultCode,r.resultData, 


r.resultExtras,r.ordered,r.initialSticky,r.userId); 


performReceiveLocked 方 法 的 实现 如 下 所 示 。 由 于 接收 广播 会 调 起 
应 用 程序 ， 因 此 app.thread 不 为 null， 根 据 前 面 的 分 析 我 们 知道 这 里 的 
app.thread{/j S48 ApplicationThread. 


private static void performReceiveLocked(ProcessRecord app, II 
receiver, 
Intent intent,int resultCode,String data,Bundle e 
boolean ordered,boolean sticky,int sendingUser) t 
// Send the intent to the receiver asynchronously using o 
if (app != null) { 
if (app.thread != null) { 
// If we have an app thread,do the call t 
// correctly ordered with other one-way c 
app.thread.scheduleRegisteredReceiver (rec 
data, extras, ordered, sticky, sendingUser, ap 
} else { 
// Application has died. Receiver doesn't 
throw new RemoteException("app.thread mus 
} 
} else { 
receiver .performReceive(intent, resultCode, data, ex 


sticky, sendingUser ); 


ApplicationThread 的 scheduleRegisteredReceiver 的 实现 比较 简单 ， 它 
通过 InnerReceiver 来 实现 广播 的 接收 ， 如 下 所 示 。 


public void scheduleRegisteredReceiver(IIntentReceiver receiv 
intent, 
int resultCode,String dataStr,Bundle extras, boole 
boolean sticky,int sendingUser, int processState) 
updateProcessState(processState, false); 


receiver .performReceive(intent, resultCode, dataStr,extras, 


InnerReceiver 的 performReceive 方 法 会 调用 
LoadedApk.ReceiverDispatcher 的 perform-Receive 方 法 ， 
LoadedApk.ReceiverDispatcher 的 performReceive 方 法 的 实现 如 下 所 示 。 


public void performReceive(Intent intent,int resultCode, Strin 
Bundle extras,boolean ordered, boolean sticky, int 
if (ActivityThread.DEBUG_BROADCAST) { 
int seq = intent.getIntExtra("seq", -1); 
Slog.i(ActivityThread.TAG, "Enqueueing broadcast " 
} 
Args args = new Args(intent, resultCode, data, extras, ordere 
sticky, sendingUser ); 
if (!mActivityThread.post(args)) { 
if (mRegistered && ordered) { 


TActivityManager mgr = ActivityManagerNat 


if (ActivityThread.DEBUG_BROADCAST) Slog. 
"Finishing sync broadcast 


args.sendFinished(mgr ); 


} 


在 上 面 的 代码 中 ， 会 创建 一 个 Args 对 象 并 通过 mActivityThread 的 
post 方 法 来 执行 Args 中 的 逻辑 ， 而 Args 实 现 了 Runnable 接 口 。 
mActivityThread 是 一 个 Handler， 它 其 实 就 是 ActivityThread 中 的 mH， 
mH 的 类 型 是 ActivityThread 的 内 部 类 H， 关 于 H 这 个 类 前 面 已 经 介绍 过 
了 ， 这 里 就 不 再 多 说 了 。 在 Args 的 run 方 法 中 有 如 下 几 行 代码 : 





final BroadcastReceiver receiver = mReceiver; 
receiver .setPendingResult(this); 


receiver .onReceive(mContext, intent); 


很 显然 ， 这 个 时 候 BroadcastReceiver 的 onReceive 方 法 被 执行 了 ， 也 
就 是 说 应 用 已 经 接收 到 广播 了 ， 同 时 onReceive 方 法 是 在 广播 接收 者 的 
主线 程 中 被 调用 的 。 到 这 里 ， 整 个 广播 的 注册 、 发 送 和 接收 过 程 已 经 分 
析 完 了 ， 读 者 应 该 对 广播 的 整个 工作 过 程 有 了 一 定 的 理解 。 








9.5 ContentProvider 的 工作 过 程 





ContentProvider 的 使 用 方法 在 第 2 章 已 经 做 了 介绍 ， 这 里 再 简单 说 明 
一 下 。ContentProvider 是 一 种 内 容 共 享 型 组 件 ， 它 通过 Binder 回 其 他 组 
件 乃 至 其 他 应 用 提供 数据 。 当 ContentProvider 所 在 的 进程 启动 时 ， 
ContentProvider 会 同时 启动 并 被 发 布 到 AMS 中 。 需 要 注意 的 是 ， 这 个 时 
候 ContentProvider 的 onCreate 要 先 于 Application 的 onCreate 而 执行 ， 这 在 
四 大 组 件 中 是 一 个 少 有 的 现象 。 





当 一 个 应 用 启动 时 ， 入 口 方法 为 ActivityThread 的 main 方 法 ，main 方 

法 是 一 个 静态 方法 ， 在 main 方 法 中 会 创建 ActivityThread 的 实例 并 创建 主 
线程 的 消息 队列 ， 然 后 在 ActivityThread 的 attach 方 法 中 会 远程 调用 AMS 
的 attachApplication 方 法 并 将 ApplicationThread 对 象 提供 给 AMS 。 
ApplicationThread 是 一 个 Binder 对 象 ， 它 的 Binder 接 口 是 
IApplicationThread， 它 主要 用 于 ActivityThread 和 AMS 之 间 的 通信 ， 这 一 
点 在 前 面 多 次 提 到 。 在 AMS 的 atata pplication A 中 ， 会 调用 
ApplicationThread 的 bindApplication 方 法 ， 注 意 这 个 过 程 同样 是 跨 进 程 完 
成 的 ，bindApplication 的 逻辑 会 经 过 ActivityThread 中 的 mH Handler 切 换 

到 ActivityThread 中 去 执行 ， 有 具体 的 方法 是 handleBindApplication。 在 
handleBindApplication 方 法 中 ，ActivityThread 会 创建 Application 对 象 并 加 
载 ContentProvider。 需 要 注意 的 是 ，ActivityThread 会 先 加 载 
ContentProvider， 然 后 再 调用 Application 的 onCreate 方 法 ， 整 个 流程 可 以 
参看 图 9-2。 
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图 9-2 ContentpProvider 的 启动 过 程 


这 就 是 ContentProvider 的 启动 过 程 ，ContentProvider 启 动 后 ， 外 界 
就 可 以 通过 它 所 提供 的 增删 改 查 这 四 个 接口 来 操作 ContentProvider 中 的 
数据 源 ， 即 insert、delete、update 和 query 四 个 方法 。 这 四 个 方法 都 是 通 
过 Binder 来 调用 的 ， 外 界 无 法 直接 访问 ContentProvider， 它 只 能 通过 
AMS 根 据 Uri 来 获取 对 应 的 ContentProvider 的 Binder 接 口 
IConentProvider， 然 后 再 通过 IConentProvider 来 访问 ContentProvider 中 的 
数据 源 。 





一 般 来 说 ，ContentProvider 都 应 该 是 单 实例 的 。ContentProvider 到 
底 是 不 是 单 实 例 ， 这 是 由 它 的 android:multiprocess 属 性 来 决定 的 ， 当 
android:multiprocess 为 false 时 ，ContentProvider 是 单 实 例 ， 这 也 是 默认 
(A; 当 android:multiprocess 为 true 时 ，ContentProvider 为 多 实例 ， 这 个 时 
候 在 每 个 调用 者 的 进程 中 都 存在 一 个 ContentProvider 对 象 。 由 于 在 实际 
的 开发 中 ， 并 未 发 现 多 实例 的 ContentProvider 的 具体 使 用 场景 ， 官 方 文 
档 中 的 解释 是 这 样 可 以 避免 进程 间 通 信 的 开销 ， 但 是 这 在 实际 开发 中 仍 


然 缺 少 使 用 价值 。 因 此 ， 我 们 可 以 简单 认为 ContentProvider 都 是 单 实 例 
的 。 下 面 分 析 单 实例 的 ContentProvider 的 启动 过 程 。 


访问 人 要 通过 ContentResolver，ContentResolver 是 一 
个 抽象 类 ， 通 过 Context 的 getContentResolver 方 法 获取 的 实际 上 是 
ae ontentResolver 对 象 ，ApplicationContentResolver 类 继承 了 
ContentResolver 并 实现 了 ContentResolver 中 的 抽象 方法 。 当 
ContentProvider 所 在 的 进程 未 启动 时 ， 第 一 次 访问 它 时 就 会 触发 
ContentProvider 的 创建 ， 当 然 这 也 伴随 着 ContentProvider 所 在 进程 的 局 
HIE ContentProvider 的 四 个 方法 的 任何 一 个 都 可 以 触发 
ContentProvider 的 启动 过 程 ， 这 里 选择 query 方 法 。 


ContentProvider 的 query 方 法 中 ， 首 先 会 获取 IContentProvider 对 象 ， 
不 管 是 通过 acquireUnstableProvider 方 法 还 TRR iWacquireProvider 77 
法 ， 它 们 的 本 质 都 是 一 样 的 ， 最 终 都 是 通过 acquireProvider 方 法 来 获取 
ContentProvider。 下 面 是 ApplicationContent-Resolver 的 acquireProvider 方 


法 的 具体 实现 : 


protected IContentProvider acquireProvider(Context context,St 
return mMainThread.acquireProvider (context, 
ContentProvider.getAuthoritywithoutUserId 


resolveUserIdFromAuthority(auth), true); 


ApplicationContentResolver 的 acquireProvider 方 法 并 没有 处 理 任 何 逻 
辑 ， 它 直接 调用 了 ActivityThread 的 acquireProvider 方 法 ，ActivityThread 
的 acquireProvider 方 法 的 源码 如 下 所 示 。 


public final IContentProvider acquireProvider ( 
Context c,String auth,int userId,boolean stable) 
final IContentProvider provider = acquireExistingProvider 
if (provider != null) { 


return provider; 


// There is a possible race here. Another thread may try 
// the same provider at the same time. When this happens, 
// that the first one wins. 
// Note that we cannot hold the lock while acquiring and 
// provider since it might take a long time to run and it 
// be re-entrant in the case where the provider is in the 
TActivityManager.ContentProviderHolder holder = null; 
try { 
holder = ActivityManagerNative.getDefault().getCo 
getApplicationThread(),auth, userI 
} catch (RemoteException ex) { 
} 
if (holder == null) { 
Slog.e(TAG, "Failed to find provider info for " + 
return null; 
t 
// Install provider will increment the reference count fo 
// any ties in the race. 
holder = installProvider(c,holder,holder.info, 
true /*noisy*/,holder .noReleaseNeeded, sta 


return holder.provider; 








上 面 的 代码 首先 会 从 ActivityThread 中 查找 是 否 已 经 存在 目标 
ContentProvider 了 ， 如 果 存 在 就 直接 返回 。ActivityThread 中 通过 
mpProviderMap 来 存储 已 经 启动 的 ContentProvider 对 象 ，mProviderMap 的 
声明 如 下 所 示 。 











final ArrayMap<providerKey,ProviderClientRecord> mProviderMap 


= new ArrayMap<providerKey, ProviderClientRecord>(); 


如 果 目 前 ContentProvider 没 有 启动 ， 那 么 MRE T 间 请 求 给 
AMS 让 其 启动 目标 ContentProvider， 最 后 再 通过 installProvider 方 法 来 修 
改 引用 计数 。 那 么 AMS 是 如 何 局 动 ContentProvider 的 呢 ? 我 们 知道 ， 
ContentProvider 被 启动 时 会 伴随 着 进程 的 启动 ， 在 AMS 中 ， 首 先 会 启动 
ContentProvider 所 在 的 进程 ， 然 后 再 启动 ContentProvider。 启 动 进程 是 
由 AMS 的 startProcessLocked 方 法 来 完成 的 ， 其 内 部 主要 是 通过 Process 的 
start 方 法 来 完成 一 个 新 进程 的 启动 ， 新 进程 启动 后 其 入 口 方 法 为 
ActivityThread 的 main 方 法 ， 如 下 所 示 。 








public static void main(String[] args) { 
SamplingProfilerIntegration.start(); 
// CloseGuard defaults to true and can be quite spammy. W 
// disable it here,but selectively enable it later (via 
// StrictMode) on debug builds, but using DropBox,not logs 
CloseGuard.setEnabled(false); 
Environment.initForCurrentuser(); 
// Set the reporter for event logging in libcore 


EventLogger.setReporter(new EventLoggingReporter()); 


Security.addProvider(new AndroidKeyStoreProvider()); 
// Make sure TrustedCertificateStore looks in the right p 
final File configDir = Environment.getUserConfigDirectory 
TrustedCertificateStore.setDefaultUserDirectory(configDir 
Process.setArgV0("<pre-initialized>"); 
Looper .prepareMainLooper(); 
ActivityThread thread = new ActivityThread(); 
thread.attach(false); 
if (sMainThreadHandler == null) { 

sMainThreadHandler = thread.getHandler(); 
Í 
AsyncTask.init(); 
if (false) { 

Looper .myLooper().setMessageLogging(new 

LogPrinter(Log.DEBUG, "ActivityThr 

Í 
Looper .loop(); 


throw new RuntimeException("Main thread loop unexpectedly 





可 以 看 到 ，ActivityThread 的 main 方 法 是 一 个 静态 方法 ， 在 它 内 部 首 
先 会 创建 Activity-Thread 的 实例 并 调用 attach 方 法 来 进行 一 系列 初始 化 ， 
接着 就 开始 进行 消息 循环 了 。ActivityThread 的 attach 方 法 会 将 
ApplicationThread 对 象 通过 AMS 的 attachApplication 方 法 跨 进 程 传递 给 
AMS， 最 终 AMS 会 完成 ContentProvider 的 创建 过 程 ， 源 码 如 下 所 示 。 


try { 


mgr .attachApplication(mAppThread) ; 
} catch (RemoteException ex) { 


// Ignore 


AMS 的 attachApplication 方 法 调用 了 attachApplicationLocked 方 法 ， 
attachApplication-Locked 中 又 调用 了 ApplicationThread 的 
bindApplication， 注 意 这 个 过 程 也 是 进程 间 调 用 ， 如 下 所 示 。 





thread.bindApplication(processName, appInfo, providers,app.inst 
profilerInfo,app.instrumentationArguments,app.ins 
app.instrumentationUiAutomationConnection, testMod 
isRestrictedBackupMode || !normalMode, app.persist 
new Configuration(mConfiguration),app.compat, getC 


mCoreSettingsObserver .getCoreSettingsLocked()); 


ActivityThread 的 bindApplication 会 发 送 一 个 BIND_APPLICATION 类 
型 的 消息 给 mH，mH 是 一 个 Handler， 它 收 到 消息 后 会 调用 
ActivityThread 的 handleBindApplication 方 法 ，bindApplication 发 送 消息 的 
过 程 如 下 所 示 。 








AppBindData data = new AppBindData(); 
data.processName = processName; 

data.appInfo = appInfo; 

data.providers = providers; 
data.instrumentationName = instrumentationName; 
data.instrumentationArgs = instrumentationArgs; 


data.instrumentationwatcher = instrumentationWwatcher; 


data. instrumentationUiAutomationConnection = instrumentationU 
data.debugMode = debugMode; 

data.enableOpenGlTrace = enableOpenGlTrace; 
data.restrictedBackupMode = isRestrictedBackupMode; 
data.persistent = persistent; 

data.config = config; 

data.compatInfo = compatInfo; 

data.initProfileriInfo = profilerinfo; 


sendMessage(H.BIND_APPLICATION, data); 


ActivityThread 的 handleBindApplication 则 完成 了 Application 的 创建 以 
及 Content-Provider 的 创建 ， 可 以 分 为 如 下 四 个 步骤 。 


1. 创建 ContextImpl 和 Instrumentation 


ContextImpl instrContext = ContextImpl.createAppContext(this, 
try { 
java.lang.ClassLoader cl = instrContext.getClassLoader(); 
mInstrumentation = (Instrumentation) 
cl.loadClass(data.instrumentationName.getClassNam 
} catch (Exception e) { 
throw new RuntimeException( 
"Unable to instantiate instrumentation " 
+ data.instrumentationName + ": " + e.toString(), 
} 
mInstrumentation.init(this, instrContext, appContext, 
new ComponentName(ii.packageName, ii.name),data.instrum 


data.instrumentationUiAutomationConnection) ; 


2. 创建 Application 对 象 


Application app = data.info.makeApplication(data.restrictedBa 


mInitialApplication = app; 
3. 启动 当前 进程 的 ContentProvider 并 调用 其 onCreate 方 法 


List<providerInfo> providers = data.providers; 

if (providers != null) { 
installContentProviders(app, providers); 
// For process that contains content providers,we want to 
// ensure that the JIT is enabled "at some point". 


mH.sendEmptyMessageDelayed(H.ENABLE_JIT,10*1000) ; 


installContentProviders 完 成 了 ContentProvider 的 启动 工作 ， 它 的 实现 
如 下 所 示 。 首 先 会 遍历 当前 进程 的 ProviderInfo 的 列表 并 一 一 调用 调用 
installProvider 方 法 来 局 动 它 们 ， 接 着 将 已 经 启动 的 ContentProvider 发 布 
到 AMS 中 ，AMS 会 把 它们 存储 在 ProviderMap 中 ， 这 样 一 来 外 部 调用 者 
就 可 以 直接 从 AMS 中 获取 ContentProvider 了 。 





private void installContentProviders( 
Context context,List<providerInfo> providers) { 
final ArrayList<IActivityManager.ContentProviderHolder> r 
new ArrayList<IActivityManager .ContentProviderHol 
for (ProviderInfo cpi : providers) { 
if (DEBUG_PROVIDER) { 
StringBuilder buf = new StringBuilder (128 
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在 上 述 代 码 中 ， 除 了 完成 ContentProvider 对 象 的 创建 ， 还 会 通过 
ContentProvider 的 attachInfo 方 法 来 调用 它 的 onCreate 方 法 ， 如 下 所 示 。 





到 此 为 止 ，ContentProvider 已 经 被 创建 并 且 其 onCreate 方 法 也 已 经 
被 调用 ， 这 意味 着 ContentProvider 已 经 启动 完成 了 。 





4. 调用 Application 的 onCreate 方 法 


try { 


mInstrumentation.callApplicationOnCreate(app); 
} catch (Exception e) { 
if (!mInstrumentation.onException(app,e)) { 
throw new RuntimeException( 
"Unable to create application " + app.get 


+": " + e,toString(),e); 


经 过 上 面 的 四 个 步骤 ，ContentProvider 已 经 成 功 启动 ， 并 且 其 所 在 
进程 的 Application 也 已 经 启动 ， 这 意味 着 ContentProvider 所 在 的 进程 已 
经 完成 了 整个 的 启动 过 程 ， 然 后 其 他 应 用 就 可 以 通过 AMS 来 访问 这 个 
ContentProvider 了 。 拿 到 了 ContentProvider 以 后 ， 就 可 以 通过 它 所 提供 
的 接口 方法 来 访问 它 了 。 需 要 注意 的 是 ， 这 里 的 ContentProvider 并 不 是 
原始 的 ContentProvider， 而 是 ContentProvider 的 Binder 类 型 的 对 象 
IContentProvider, IContentProvider ft) 4/4 SKI ContentProviderNative Fil 
ContentProvider.Transport， 其 中 ContentProvider.Transport 继 承 了 
ContentProviderNative。 这 里 仍然 选择 query 方 法 ， 首 先 其 他 应 用 会 通过 
AMS 获 取 到 ContentProvider 的 Binder 对 象 即 IContentProvider， 而 
IContentProvider 的 实现 者 实际 上 是 ContentProvider.Transport。 因 此 其 他 











应 用 调用 IContentProvider 的 query 方 法 时 最 终 会 以 进程 间 通信 的 方式 调 
用 到 ContentProvider.Transport 的 query 方 法 ， 它 的 实现 如 下 所 示 。 





public Cursor query(String callingPkg,Uri uri,String[] projec 
String selection, String[] selectionArgs, String so 
ICancellationSignal cancellationSignal) { 
validateIncomingUri(uri); 
uri = getUriWithoutUserId(uri); 
if (enforceReadPermission(callingPkg,uri) != AppOpsManage 
return rejectQuery(uri, projection, selection, selec 
CancellationSignal.fromTransport( 
j; 
final String original = setCallingPackage(callingPkg); 
try { 
return ContentProvider.this.query( 
uri,projection,selection,selectio 
CancellationSignal.fromTransport( 
} finally { 


setCallingPackage(original); 


很 显然 ，ContentProvider.Transport 的 query 方 法 调用 了 
ContentProvider 的 query 方 法 ，query 方 法 的 执行 结果 再 通过 Binder 返 回 给 
调用 者 ， 这 样 一 来 整个 调用 过 程 就 完成 了 。 除 了 query 方 法 ，insert、 
delete 和 update 方 法 也 是 类 似 的 ， 这 里 就 不 再 分 析 了 。 


第 10 董 ”Android 的 消息 机 制 


本 章 所 要 讲述 的 内 容 是 Android 的 消息 机 制 。 提 到 消息 机 制 读 者 应 

该 都 不 陌生 ， 在 日 党 开发 中 不 可 避免 地 要 涉及 这 方面 的 内 容 。 从 开发 的 
角度 来 说 ，Handler 是 Android 消 息 机 制 的 上 层 接口 ， 这 使 得 在 开发 过 程 
中 只 需要 和 Handler 交 互 即 可 。Handler 的 使 用 过 程 很 简单 ， 通 过 它 可 以 
轻松 地 将 一 个 任务 切换 到 Handler 所 在 的 线程 中 去 执行 。 很 多 人 认为 
Handler 的 作用 是 更 新 UI， 这 的 确 没 错 ， 但 是 更 新 UI 仅 仅 是 Handler 的 一 
个 特殊 的 使 用 场景 。 有 具体 来 说 是 这 样 的 : 有 时 候 需 要 在 子 线程 中 进行 耗 
时 的 VO 操作 ， 可 能 是 读 取 文件 或 者 访问 网 络 等 ， 当 耗 时 操作 完成 以 后 

可 能 需要 在 UI 上 做 一 些 改变 ， 由 于 Android 开 发 规范 的 限制 ， 我 们 并 不 

能 在 子 线程 中 访问 UI 控件 ， 否 则 就 会 触发 程序 异常 ， 这 个 时 候 通 过 
Handler 就 可 以 将 更 新 UI 的 操作 切换 到 主线 程 中 执行 。 因 此 ， 本 质 上 来 
说 ，Handler 并 不 是 专门 用 于 更 新 UI 的 ， 它 只 是 常 被 开发 者 用 来 更 新 
UI. 

















Android 的 消息 机 制 主要 是 指 Handler 的 运行 机 制 ，Handler 的 运行 需 

要 底层 的 MessageQueue 和 Looper 的 文 撑 。MessageQueue 的 中 文 翻译 是 消 
恩 队 列 ， 顾 名 思 义 ， 它 的 内 部 存储 了 一 组 消息 ， 以 队列 的 形式 对 外 提供 
插入 和 删除 的 工作 。 虽 然 叫 消 轧 队列 ， 但 是 它 的 内 部 存储 结构 并 不 是 真 
正 的 队列 ， 而 是 采用 单 链 表 的 数据 结构 来 存储 消息 列表 。Looper 的 中 文 
翻译 为 循环 ， 在 这 里 可 以 理解 为 消息 循环 。 由 于 MessageQueue 只 是 一 个 
消息 的 存储 单元 ， 它 不 能 去 处 理 消息 ， 而 Looper 束 填补 了 这 个 功能 

Looper 会 以 无 限 循环 的 形式 去 碍 找 是 否 有 新 消息 ， 如 果 有 的 话 就 处 理 消 





上 县， 否则 天 一 直 等 待 着 。Looper 中 还 有 一 个 特殊 的 概念 ， 那 就 是 
ThreadLocal， 是 线程 ， 它 的 作用 是 可 以 在 每 个 线程 中 
存储 数据 。 我 们 知道 ，Handler 创 建 的 时 候 会 采用 当前 线程 的 Looper 来 构 
造 消息 循环 系统 ， 那 么 Handler 内 部 如 何 获 取 到 当前 线程 的 Looper 呢 ?这 
a ThreadLocal 可 以 在 不 同 的 线程 中 互 不 干扰 地 
存储 并 提供 数据 ， 通 过 ThreadLocal 可 以 轻松 获取 每 个 线程 的 Looper。 当 
然 需 要 注意 的 是 ， - 是 默认 没有 Looper 的 ， 如 果 需 要 使 用 Handler 就 必 
须 为 线程 创建 Looper。 我 们 经 常 提 到 的 主线 程 ， 也 叫 UI 线 程 ， 它 就 是 
ActivityThread，ActivityThread 被 创建 时 就 会 初始 化 Looper， 这 也 是 在 主 


线程 中 默认 可 以 使 用 Handler 的 原因 。 


10.1 Android 的 消 因 机 制 概述 


前 面 提 到 ，Android 的 消息 机 制 主 要 是 指 Handler 的 运行 机 制 以 及 
Handler 所 附带 的 MessageQueue 和 Looper 的 工作 过 程 ， 这 三 者 实际 上 是 
一 个 整体 ， 只 不 过 我 们 在 开发 过 程 中 比较 多 地 接触 到 Handler 而 已 。 
Handler 的 主要 作用 是 将 一 个 任务 切换 到 某 个 指定 的 线程 中 去 执行 ， 那 
么 Android 为 什么 要 提供 这 个 功能 呢 ? 或 者 说 Android 为 什么 需要 提供 在 
某 个 具体 的 线程 中 执行 任务 这 种 功能 呢 ? 这 是 因为 Android 规 定 访问 UI 

只 能 在 主线 程 中 进行 ， MRE eke) JUL, ASA REA wt Hh 

。 ViewRootImpl 对 UI 操作 做 了 验证 ， 这 个 验证 工作 是 由 ViewRootImpl 

i checkThread 方 法 来 完成 的 ， 如 下 所 示 。 





void checkThread() { 
if (mThread != Thread.currentThread()) { 


throw new CalledFromWrongThreadException("Only th 


} 


针对 checkThread 方 法 中 抛 出 的 异常 信息 ， 相 信 读 者 在 开发 中 都 曾经 
遇 到 过 。 由 于 这 一 点 的 限制 ， 导 致 必须 在 主线 程 中 访问 UI， 但 是 
Android 又 建议 不 要 在 主线 程 中 进行 耗 时 操作 ， 人 否则 会 导致 程序 无 法 啊 
应 即 ANR。 aa 种 情况 ， 假 如 我 们 需要 从 服务 端 拉 取 一 些 信息 并 将 其 
显示 在 UI 上 ， 这 个 时 候 必 须 在 子 线程 中 进行 拉 取 工作 ， 拉 取 完 毕 后 又 不 
能 在 子 线程 中 直接 访问 UI， 如 果 没 有 Handler， 那 么 我 们 的 确 没有 办 法 
将 访问 UI 的 工作 切换 到 主线 程 中 去 执行 。 因此， 系统 之 所 以 提供 
Handler， 主 要 原因 束 是 为 了 解决 在 子 线程 中 无 法 访问 UI 的 矛盾 。 

















这 里 再 延伸 一 点 ， 系 统 为 什么 不 允许 在 子 线程 中 访问 UI 呢 ? 这 是 因 
为 Android 的 UI 控 件 不 是 线程 安全 的 ， 如 果 在 多 线程 中 并 发 访问 可 能 会 
导致 UI 控件 处 于 不 可 预期 的 状态 ， 那 为 什么 系统 不 对 UI 控件 的 访问 加 上 
锁 机 制 呢 ? 缺点 有 两 个 : 首先 加 上 锁 机 制 会 让 UI 访问 的 逻辑 变 得 复杂 ; 
其 次 锁 机 制 会 降低 UI 访 问 的 效率 ， 因 为 锁 机 制 会 阻塞 茶 些 线程 的 执行 。 
鉴于 这 两 个 缺 点 ， 最 简单 且 高 效 的 方法 就 是 采用 单线 程 模型 来 处 理 UI 操 
作 ， 对 于 开发 者 来 说 也 不 是 很 抹 烦 ， 只 是 需要 通过 Handler 切 换 一 下 UI 
访问 的 执行 线程 即 可 。 


Handler 的 使 用 方法 这 里 就 不 做 介绍 了 ， 这 里 摘 述 一 下 Handler 的 工 
作 原 理 。Handler 创 建 时 会 采用 当前 线程 的 Looper 来 构建 内 部 的 消息 循环 
系统 ， 如 果 当 前 线程 没有 Looper， 那 么 就 会 报错 ， 如 下 所 示 。 


E/AndroidRuntime(27568): FATAL EXCEPTION: Thread-43484 
E/AndroidRuntime(27568): java.lang.RuntimeException: Can't cr 
E/AndroidRuntime(27568): at android.os.Handler.<init>(Handler 


E/AndroidRuntime(27568): at com.ryg.chapter_ 10.TestActi 


如 何 解决 上 述 问 题 呢 ? 其 实 很 简单 ， 只 需要 为 当前 线程 创建 Looper 
即 可 ， 或 者 在 一 个 有 Looper 的 线程 中 创建 Handler 也 行 ， 有 具体 会 在 10.2.3 
节 中 进行 介绍 。 


Handler 创 建 完毕 后 ， 这 个 时 候 其 内 部 的 Looper 以 及 MessageQueue 
就 可 以 和 Handler 一 起 协同 工作 了 ， 然 后 通过 Handler 的 post 方 法 将 一 个 
Runnable 投 递 到 Handler 内 部 的 Looper 中 去 处 理 ， 也 可 以 通过 Handler 的 
send 方 法 发 送 一 个 消 忠 ， 这 个 消 奶 同样 会 在 Looper 中 去 处 理 。 其 实 post 
方法 最 终 也 是 通过 send 方 法 来 完成 的 ， 接 下 来 主要 来 看 一 下 send 方 法 的 
工作 过 程 。 当 Handler 的 send 方 法 被 调用 时 ， 它 会 调用 MessageQueue 的 








endueueMessage 方 法 将 这 个 消息 放 入 消息 队列 中 ， 然 后 Looper 发 现 有 新 
消息 到 来 时 ， 就 会 处 理 这 个 消息 ， 最 终 消 恩 中 的 Runnable 或 者 Handler 的 
handleMessage 方 法 就 会 被 调用 。 注 意 Looper 是 运行 在 创建 Handler 所 在 
的 线程 中 的 ， 这 样 一 来 Handler 中 的 业务 逻辑 就 被 切换 到 创建 Handler 所 
在 的 线程 中 去 执行 了 ， 这 个 过 程 可 以 用 图 10-1 来 表示 。 
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图 10-1 Handler 的 工作 过 程 
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在 10.1 节 中 对 Android 的 消息 机 制 已 经 做 了 一 个 概括 性 的 描述 ， 通 过 
图 10-1 也 能 够 比较 好 地 理解 Handler 的 工作 过 程 。 本 节 将 对 Android 消 息 
机 制 的 实现 原理 做 一 个 全 面 的 分 析 。 由 于 Android 的 消息 机 制 实际 上 束 
是 Handler 的 运行 机 制 ， 因 此 本 节 主 要 围绕 着 Handler 的 工作 过 程 来 分 析 
Android 的 消息 机 制 ， 主 要 包括 Handler、MessageQueue 和 Looper。 同 时 
为 了 更 好 地 理解 Looper 的 工作 原理 ， 本 节 还 会 介绍 ThreadLocal， 通 过 本 
节 的 介绍 可 以 让 读者 对 Android 的 消息 机 制 有 一 个 深入 的 理解 。 





10.2.1 ThreadLocal 的 工作 原理 





ThreadLocal 是 一 个 线程 内 部 的 数据 存储 类 ， 通 过 它 可 以 在 指定 的 线 
程 中 存储 数据 ， 数 据 存储 以 后 ， 只 有 在 指定 线程 中 可 以 获取 到 存储 的 数 
据 ， 对 于 其 他 线程 来 说 则 无 法 获取 到 数据 。 在 日 党 开发 中 用 到 
ThreadLocal 的 地 方 较 少 ， 但 是 在 某 些 特殊 的 场景 下 ， 通 过 ThreadLocal 
可 以 轻松 地 实现 一 些 看 起 来 很 复杂 的 功能 ， 这 一 点 在 Android 的 源码 中 
也 有 所 体现 ， 比 如 Looper、ActivityThread 以 及 AMS 中 都 用 到 了 
ThreadLocal。 县 体 到 ThreadLocal 的 使 用 场景 ， 这 个 不 好 统一 来 描述 ， 
一 般 来 说 ， 当 某 些 数据 是 以 线程 为 作用 域 并 且 不 同 线程 具有 不 同 的 数据 
副本 的 时 候 ， 就 可 以 考虑 采用 ThreadLocal。 比 如 对 于 Handler 来 说 ， 它 
需要 获取 当前 线程 的 Looper， 很 显然 Looper 的 作用 域 就 是 线程 并 且 不 同 
线程 具有 不 同 的 Looper， 这 个 时 候 通 过 ThreadLocal 束 可 以 轻松 实现 
Looper 在 线程 中 的 存 取 。 如 果 不 采 用 ThreadLocal， 那 么 系统 束 必 须 提供 























一 个 全 局 的 哈 希 表 供 Handler 查 找 指定 线程 的 Looper， 这 样 一 来 束 必 须 提 
供 一 个 类 似 于 LooperManager 的 类 了 ， 但 是 系统 并 没有 这 么 做 而 是 选择 
了 ThreadLocal， 这 就 是 ThreadLocal 的 好 处 。 


ThreadLocal 为 一 个 使 用 场景 是 复杂 逻辑 下 的 对 象 传 递 ， 比 如 监听 器 
的 传递 ， 有 些 时 候 一 个 线程 中 的 任务 过 于 复杂 ， 这 可 能 表现 为 函数 调用 
栈 比较 深 以 及 代码 入 口 的 多 样 性 ， 在 这 种 情况 下 ， 我 们 又 需要 监听 器 能 
够 贯穿 整个 线程 的 执行 过 程 ， 这 个 时 候 可 以 怎么 做 呢 ? 其 实 这 时 就 可 以 
采用 ThreadLocal， 采 用 ThreadLocal 可 以 让 监听 器 作为 线程 内 的 全 局 对 
象 而 存在 ， 在 线程 内 部 只 要 通过 get 方 法 就 可 以 获取 到 监听 器 。 如 果 不 
采用 ThreadLocal， 那 么 我 们 能 想到 的 可 能 是 如 下 两 种 方法 : 第 一 种 方法 
是 将 监 昕 器 通过 参数 的 形式 在 函数 调用 栈 中 进行 传递 ， 第 二 种 方法 就 是 
将 监听 器 作为 静态 变量 供 线程 访问 。 上 述 这 两 种 方法 都 是 有 局 限 性 的 。 
第 一 种 方法 的 问题 是 当 函 数 调用 栈 很 深 的 时 候 ， 通 过 函数 参数 来 传递 监 
昕 器 对 象 这 几乎 是 不 可 接受 的 ， 这 会 让 程序 的 设计 看 起 来 很 糟 闵 。 第 二 
种 方法 是 可 以 接受 的 ， 但 是 这 种 状态 是 不 具有 可 扩充 性 的 ， 比 如 同时 有 
两 个 线程 在 执行 ， 那 么 就 需要 提供 两 个 静态 的 监听 器 对 象 ， 如 果 有 10 个 
线程 在 并 发 执行 呢 ? 提供 10 个 静态 的 监听 器 对 象 ? 这 显然 是 不 可 思议 
的 ， 而 采用 ThreadLocal， 每 个 监听 器 对 象 都 在 自己 的 线程 内 部 存储 ， 根 
本 就 不 会 有 方法 2 的 这 种 问题 。 























介绍 了 那么 多 ThreadLocal 的 知识 ， 可 能 还 是 有 点 抽象 ， 下 面 通过 实 
际 的 例子 来 演示 ThreadLocal 的 真正 含义 。 首 先 定义 一 个 ThreadLocal 对 
象 ， 这 里 选择 Boolean 类 型 的 ， 如 下 所 示 。 


private ThreadLocal<Boolean> mBooleanThreadLocal = new Thread 





然后 分 别 在 主线 程 、 子 线程 1 和 子 线程 2 中 设置 和 访问 它 的 值 ， 代 码 


如 下 所 示 。 


mBooleanThreadLocal.set(true); 
Log.d(TAG, "[Thread#main]mBooleanThreadLocal=" + mBooleanThrea 
new Thread("Thread#1") { 
@Override 
public void run() { 
mBooleanThreadLocal.set(false); 
Log.d(TAG, "[Thread#1]mBooleanThreadLocal=" + mBoo 
}; 
}.start(); 
new Thread("Thread#2") { 
@Override 
public void run() { 
Log.d(TAG, "[Thread#2 ]mBooleanThreadLocal=" + mBoo 
}; 
}.start(); 





在 上 面 的 代码 中 ， 在 主线 程 中 设置 mBooleanThreadLocal 的 值 为 
true， 在 子 线程 1 中 设置 mBooleanThreadLocal 的 值 为 false， 在 子 线程 2 中 
不 设置 mBooleanThreadLocal 的 值 。 然 后 分 别 在 3 个 线程 中 通过 get 方 法 获 
取 mBooleanThreadLocal 的 值 ， 根 据 前 面 对 ThreadLocal 的 描述 ， 这 个 时 
候 ， 主 线程 中 应 该 是 kue， 子 线程 1 中 应 该 是 false， 而 子 线程 2 中 由 于 没 
有 设置 值 ， 所 以 应 该 是 null。 安 装 并 运行 程序 ， 日 志 如 下 所 示 。 





D/TestActivity(8676): [Thread#main]mBooleanThreadLocal=true 
D/TestActivity(8676): [Thread#1]mBooleanThreadLocal=false 
D/TestActivity(8676): [Thread#2]mBooleanThreadLocal=null 


从 上 面 日 志 可 以 看 出 ， 虽 然 在 不 同 线程 中 访问 的 是 同一 个 
ThreadLocal 对 象 ， 但 是 它们 通过 ThreadLocal 获 取 到 的 值 却 是 不 一 样 
的 ， 这 束 是 ThreadLocal 的 奇妙 之 处 。 结 合 这 个 例子 然后 再 看 一 遍 前 面 对 
ThreadLocal 的 两 个 使 用 场景 的 理论 分 析 ， 我 们 应 该 束 能 比较 好 地 理解 
ThreadLocal 的 使 用 方法 了 。ThreadLocal 之 所 以 有 这 么 奇妙 的 效果 ， 是 
因为 不 同 线程 访问 同一 个 ThreadLocal 的 get 方 法 ，ThreadLocal 内 部 会 从 
各 目的 线程 中 取出 一 个 数组 ， 然 后 再 从 数组 中 根据 当前 ThreadLocal 的 索 
引 去 查找 出 对 应 的 value 值 。 很 显然 ， 不 同 线程 中 的 数组 是 不 同 的 ， 这 就 
是 为 什么 通过 ThreadLocal 可 以 在 不 同 的 线程 中 维护 一 套数 据 的 副本 并 且 
彼此 互 不 干扰 。 





对 ThreadLocal 的 使 用 方法 和 工作 过 程 做 了 介绍 后 ， 下 面 分 析 
ThreadLocal 的 内 部 实现 ，ThreadLocal 是 一 个 泛 型 类 ， 它 的 定义 为 public 
class ThreadLocal<T>， 只 要 弄 清 楚 ThreadLocal 的 get 和 和 set 方法 就 可 以 明 
白 它 的 工作 原理 。 


首先 看 ThreadLocal 的 set 方 法 ， 如 下 所 示 。 


public void set(T value) { 
Thread currentThread = Thread.currentThread(); 
Values values = values(currentThread) ; 
if (values == null) { 
values = initializeValues(currentThread) ; 
i 
values.put(this, value) ; 


} 





在 上 面 的 set 方 法 中 ， 首 先 会 通过 values 方 法 来 获取 当前 线程 中 的 





ThreadLocal 数 据 ， 如 何 获取 呢 ? 其 实 获取 的 方式 也 是 很 简单 的 ， 在 
Thread 类 的 内 部 有 一 个 成 员 专 门 用 于 存储 线程 的 ThreadLocal 的 数据 : 
ThreadLocal.Values ”localValues， 因 此 获取 当前 线程 的 ThreadLocal 数 据 
就 变 得 异常 简单 了 。 如 果 localValues 的 值 为 null， 那 么 就 需要 对 其 进行 
初始 化 ， 初 始 化 后 再 将 ThreadLocal 的 值 进行 存储 。 下 面 看 一 下 
ThreadLocal 的 值 到 底 是 如 何在 localValues 中 进行 存储 的 。 在 localValues 
内 部 有 一 个 数组 : private Object[] table，ThreadLocal 的 值 就 存在 在 这 个 
table 数 组 中 。 下 面 看 一 下 localValues 是 如 何 使 用 put 方 法 将 ThreadLocal 的 
值 存储 到 table 数 组 中 的 ， 如 下 所 示 。 





void put(ThreadLocal<?> key,Object value) { 
cleanUp(); 
// Keep track of first tombstone. That's where we want to 
// and add an entry if necessary. 
int firstTombstone = -1; 
for (int index = key.hash & mask;; index = next(index)) { 
Object k = table[index]; 
if (k == key.reference) { 
// Replace existing entry. 
table[index + 1] = value; 
return; 
J 
if (k == null) 4 
if (firstTombstone == -1) { 
// Fill in null slot. 
table[index] = key.reference; 


table[index + 1] = value; 








上 面 的 代码 实现 了 数据 的 存储 过 程 ， 这 里 不 去 分 析 它 的 具体 算法 ， 
但 是 我 们 可 以 得 出 一 个 存储 规则 ， 那 就 是 ThreadLocal 的 值 在 table 数 组 中 
的 存储 位 置 总 是 为 ThreadLocal 的 reference 字 段 所 标识 的 对 象 的 下 一 个 位 
置 ， 比 如 ThreadLocal 的 reference 对 象 在 table 数 组 中 的 索引 为 iIndex， 那 么 
ThreadLocal 的 值 在 table 数 组 中 的 索引 就 是 index+1。 最 终 ThreadLocal 的 
值 将 会 被 存储 在 table 数 组 中 : table[index + 1] = value。 


上 面 分 析 了 ThreadLocal 的 set 方 法 ， 这 里 分 析 它 的 get 方 法 ， 如 下 所 
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可 以 发 现 ，ThreadLocal 的 get 方 法 的 逻辑 也 比较 清晰 ， 它 同样 是 取 
出 当前 线程 的 local-Values 对 象 ， 如 果 这 个 对 象 为 null 那 么 就 返回 初始 
值 ， 初 始 值 由 ThreadLocal 的 initialValue 方 法 来 描述 ， 默 认 情 况 下 为 
null， 当 然 也 可 以 重 写 这 个 方法 ， 它 的 默认 实现 如 下 所 示 。 





return null; 


} 


如 果 1localValues 对 象 不 为 null， 那 就 取出 它 的 table 数 组 并 找 出 
ThreadLocal 的 reference 对 象 在 table 数 组 中 的 位 置 ， 然 后 table 数 组 中 的 下 
一 个 位 置 所 存储 的 数据 就 是 ThreadLocal 的 值 。 


从 ThreadLocal 的 set 和 get 方法 可 以 看 出 ， 它 们 所 操作 的 对 象 都 是 当 
前 线程 的 localValues 对 象 的 table 数 组 ， 因 此 在 不 同 线程 中 访问 同一 个 
ThreadLocal 的 set 和 和 get 方法， 它们 对 ThreadLocal 所 做 的 读 / 写 操作 仅 限 于 
各 自 线程 的 内 部 ， 这 就 是 为 什么 ThreadLocal 可 以 在 多 个 线程 中 互 不 干扰 
地 存储 和 修改 数据 ， 理 解 ThreadLocal 的 实现 方式 有 助 于 理解 Looper 的 工 
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10.2.2 ” 消 居 队列 的 工作 原理 


消息 队列 在 Android 中 指 的 是 MessageQueue，MessageQueue 主 要 包 
含 两 个 操作 :插入 和 读 取 。 读 取 操 作 本 里 会 伴随 厦 删 除 操作 ， 插 入 和 读 
取 对 应 的 方法 分 别 为 enqueueMessage 和 next， 其 中 enqueueMessage 的 作 
用 是 往 消息 队列 中 插入 一 条 消息 ， 而 next 的 作用 是 从 消息 队列 中 取出 一 
条 消息 并 将 其 从 消息 队列 中 移 除 。 尽 管 MessageQueue 叫 消息 队列 ， 但 是 
它 的 内 部 实现 并 不 是 用 的 队列 ， 实 际 上 它 是 通过 一 个 单 链 表 的 数据 结构 
来 维护 消息 列表 ， 单 链表 在 插入 和 删除 上 比较 有 优势 。 下 面 主 要 看 一 下 
它 的 enqueueMessage 和 next 方 法 的 实现 ，enqueueMessage 的 源码 如 下 所 
示 。 


boolean enqueueMessage(Message msg,long when) { 





从 enqueueMessage 的 实现 来 看 ， 它 的 主要 操作 其 实 就 是 单 链表 的 插 
入 操作 ， 这 里 就 不 再 过 多 解释 了 ， 下 面 看 一 下 next 方 法 的 实现 ，next 的 
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// No more messages. 


nextPollTimeoutMillis = -1; 


} 


可 以 发 现 next 方 法 是 一 个 无 限 循 环 的 方法 ， 如 果 消 息 队 列 中 没有 消 
息 ， 那 么 next 方 法 会 一 直 阻 塞 在 这 里 。 当 有 新 消息 到 来 时 ，next 方 法 会 
返回 这 条 消息 并 将 其 从 单 链表 中 移 除 。 


10.2.3 Looper 的 工作 原理 


在 10.2.2 节 中 介绍 了 消息 队列 的 主要 实现 ， 本 节 将 分 析 Looper 的 有 具 
体 实 现 。Looper 在 Android 的 消息 机 制 中 扮演 痢 消 息 循 环 的 角色 ， 有 具体 
来 说 就 是 它 会 不 停 地 从 MessageQueue 中 查看 是 否 有 新 消息 ， 如 果 有 新 消 
恩 就 会 立刻 处 理 ， 否 则 就 一 直 阻 塞 在 那里 。 痛 先 看 一 下 它 的 构造 方法 ， 
在 构造 方法 中 它 会 创建 一 个 MessageQueue 即 消息 队列 ， 然 后 将 当前 线程 
的 对 象 保存 起 来 ， 如 下 所 示 。 




















private Looper(boolean quitAllowed) { 
mQueue = new MessageQueue(quitAllowed) ; 


mThread = Thread.currentThread(); 


我 们 知道 ，Handler 的 工作 需要 Looper， 没 有 Looper 的 线程 就 会 报 
昔 ， 那 么 如 何 为 一 个 线程 创建 Looper 呢 ? 其 实 很 简单 ， 通 过 
Looper.prepare() 即 可 为 当前 线程 创建 一 个 Looper， 接 着 通过 
Looper.loop0 来 开局 消息 循环 ， 如 下 所 示 。 


new Thread("Thread#2") { 
@Override 
public void run() { 
Looper.prepare(); 
Handler handler = new Handler(); 
Looper.loop(); 
ti 
}.start(); 


Looper 除 了 prepare 方 法 外 ， 还 提供 了 prepareMainLooper 方 法 ， 这 个 
方法 主要 是 给 主线 程 也 就 是 ActivityThread 创 建 Looper 使 用 的 ， 其 本 质 也 
是 通过 prepare 方 法 来 实现 的 。 由 于 主线 程 的 Looper 比 较 特 殊 ， 所 以 
Looper 提 供 了 一 个 getMainLooper 方 法 ， 通 过 它 可 以 在 任何 地 方 获取 到 主 
线程 的 Looper。Looper 也 是 可 以 退出 的 ，Looper 提 供 了 quit 和 quitSafely 
来 退出 一 个 Looper， 二 者 的 区 别 是 : quit 会 直接 退出 Looper， 而 
quitSafely 只 是 设 定 一 个 退出 标记 ， 然 后 把 消息 队列 中 的 已 有 消息 处 理 完 
毕 后 才 安 全 地 退出 。Looper 退 出 后 ， 通 过 Handler 发 送 的 消息 会 失败 ， 这 
个 时 候 Handler 的 send 方 法 会 返回 false。 在 子 线程 中 ， 如 果 手 动 为 其 创建 
了 Looper， 那 么 在 所 有 的 事情 完成 以 后 应 该 调用 quit 方 法 来 终止 消息 循 
环 ， 盏 则 这 个 子 线程 束 会 一 直 处 于 等 待 的 状态 ， 而 如 果 退 出 Looper 以 
后 ， 这 个 线程 束 会 立刻 终止 ， 因 此 建议 不 需要 的 时 候 终 止 Looper。 























Looper 最 重要 的 一 个 方法 是 loop 方 法 ， 只 有 调用 了 loop 后 ， 消 息 循 


环 系统 才 会 真正 地 起 作用 ， 它 的 实现 如 下 所 示 。 





} 


msg.target.dispatchMessage(msg); 
if (logging != null) { 
logging. printin("<<<<< Finished to " + ms 
J 
// Make sure that during the course of dispatchin 
// identity of the thread wasn't corrupted. 
final long newIdent = Binder.clearCallingIdentity 
if (ident != newlIdent) { 
Log.wtf (TAG, "Thread identity changed from 
+ Long. toHexString(ident ) 
+ Long. toHexString(newIde 
+ msg.target.getClass().g 
+ msg.callback + " what=" 


} 


msg.recycleUnchecked(); 





Looper 的 loop 方 法 的 工作 过 程 也 比较 好 理解 ，loop 方 法 是 一 个 死 循 
环 ， 唯 一 跳出 循环 的 方式 是 MessageQueue 的 next 方 法 返回 了 null。 当 
Looper 的 quit 方 法 被 调用 时 ，Looper 就 会 调用 MessageQueue 的 quit 或 者 
quitSafely 方 法 来 通知 消息 队列 退出 ， 当 消息 队列 被 标记 为 退出 状态 时 ， 
它 的 next 方 法 就 会 返回 null。 也 就 是 说 ，Looper 必 须 退 出 ， 否 则 loop 方 法 
就 会 无 限 循 环 下 去 。loop 方 法 会 调用 MessageQueue 的 next 方 法 来 获取 新 
消息 ， 而 next 是 一 个 阻塞 操作 ， 当 没有 消 恩 时 ，next 方 法 会 一 直 阻 塞 在 
那里 ， 这 也 导致 oop 方 法 一 直 阻 塞 在 那里 。 如 果 MessageQueue 的 next 方 





法 返回 了 新 消息 ，Looper 就 会 处 理 这 条 消息 : 
msg.target.dispatchMessage(msg)， 这 里 的 msg.target 是 发 送 这 条 消息 的 
Handler 对 象 ， 这 样 Handler 发 送 的 消息 最 终 又 交 给 它 的 dispatchMessage 
方法 来 处 理 了 。 但 是 这 里 不 同 的 是 ，Handler 的 dispatchMessage 方 法 是 在 
创建 Handler 时 所 使 用 的 Looper 中 执行 的 ， 这 样 束 成功 地 将 代码 逻辑 切换 
到 指定 的 线程 中 去 执行 了 。 


10.2.4 Handler 的 工作 原理 


Handler 的 工作 主要 包含 消息 的 发 送 和 接收 过 程 。 消 息 的 发 送 可 以 
通过 p 系列 方法 以 及 send 的 一 系列 方法 来 实现 ，post 的 一 系列 方法 
最 终 是 通过 send 的 一 系列 方法 来 实现 的 。 发 送 一 条 消息 的 典型 过 程 如 下 





public final boolean sendMessage(Message msg) 
x 
return sendMessageDelayed(msg,0); 
t 
public final boolean sendMessageDelayed(Message msg,long dela 
{ 
if (delayMillis < 0) { 
delayMillis = 0; 
$ 
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + 
Í 


public boolean sendMessageAtTime(Message msg,long uptimeMilli 


MessageQueue queue = mQueue; 
if (queue == null) { 
RuntimeException e = new RuntimeException( 
this + " sendMessageAtTime() call 
Log.w("Looper",e.getMessage(),e); 
return false; 


} 


return enqueueMessage(queue, msg, uptimeMillis); 
} 
private boolean enqueueMessage(MessageQueue queue,Message msg 
uptimeMillis) { 
msg.target = this; 
if (mAsynchronous) { 
msg.setAsynchronous(true); 


} 


return queue.enqueueMessage(msg, uptimeMillis); 


可 以 发 现 ，Handler 发 送 消 息 的 过 程 仅仅 是 同 消 息 队 列 中 插入 了 一 
条 消息 ，MessageQueue 的 next 方 法 束 会 返回 这 条 消息 给 Looper，Looper 
收 到 消息 后 就 开始 处 理 了 ， 最 终 消 恩 由 Looper 交 由 Handler 处 理 ， 即 
Handler 的 dispatchMessage 方 法 会 被 调用 ， 这 时 Handler 束 进入 了 处 理 消 
息 的 阶段 。dispatchMessage 的 实现 如 下 所 示 。 








public void dispatchMessage(Message msg) { 
if (msg.callback != null) { 
handleCallback(msg)j; 





Handler 处 理 消 息 的 过 程 如 下 : 


首先 ， 检 查 Message 的 callback 是 否 为 null， 不 为 null 就 通过 
handleCallback 来 处 理 消息 。Message 的 callback 是 一 个 Runnable 对 象 ， 实 
际 上 就 是 Handler 的 post 方 法 所 传递 的 Runnable 参 数 。handleCallback 的 逻 
辑 也 是 很 简单 ， 如 下 所 示 。 





其 次 ， 检 查 mCallback 是 否 为 null， 不 为 null 就 调用 mCallback 的 
handleMessage 方 法 来 处 理 消息 。Callback 是 个 接口 ， 它 的 定义 如 下 : 





* @param msg A {@link android.os.Message Message} object 
* @return True if no further handling is desired 
we 
public interface Callback { 
public boolean handleMessage(Message msg); 


i 


通过 Callback 可 以 采用 如 下 方式 来 创建 Handler 对 象 : Handler 
handler = new Handler(callbacl)。 那 么 Callback 的 意义 是 什么 昵 ? 源码 里 
面 的 注释 已 经 做 了 说 明 : 可 以 用 来 创建 一 个 Handler 的 实例 但 并 不 需要 
派生 Handler 的 子 类 。 在 日 常 开 发 中 ， 创 建 Handler 最 常见 的 方式 就 是 派 
生 一 个 Handler 的 子 类 并 重 写 其 handleMessage 方 法 来 处 理 具体 的 消息 ， 
而 Callback 给 我 们 提供 了 另外 一 种 使 用 Handler 的 方式 ， 当 我 们 不 想 派 生 
子 类 时 ， 就 可 以 通过 Callback 来 实现 。 











最 后 ， 调 用 Handler 的 handleMessage 方 法 来 处 理 消息 。Handler 处 理 
消息 的 过 程 可 以 归纳 为 一 个 流程 图 ， 如 图 10-2 所 示 。 
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Y -一 msg.callback = | 
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图 10-2 Handler 消 息 处 理 流 程 图 


Handler 还 有 一 个 特殊 的 构造 方法 ， 那 就 是 通过 一 个 特定 的 Looper 来 
构造 Handler， 它 的 实现 如 下 所 示 。 通 过 这 个 构造 方法 可 以 实现 一 些 特 
殊 的 功能 。 








public Handler(Looper looper) { 


下 面 看 一 下 Handler 的 一 个 默认 构造 方法 public Handler()， 这 个 构造 
方法 会 调用 下 面 的 构造 方法 。 很 明显 ， 如 果 当 前 线程 没有 Looper 的 话 ， 
就 会 抛 出 “Can't create handler inside thread that has not called 





Looper.prepare()” 这 个 异常 ， 这 也 解释 了 在 没有 Looper 的 子 线程 中 创建 
Handler 会 引发 程序 异常 的 原因 。 





10.3 ”主线 程 的 消息 循环 


Android 的 主线 程 就 是 ActivityThread， 主 线程 的 入 口 方法 为 main， 
在 main 方 法 中 系统 会 通过 Looper.prepareMainLooper() 来 创建 主线 程 的 
Looper 以 及 MessageQueue， 并 通过 Looper.loop0) 来 开启 主线 程 的 消息 循 
环 ， 这 个 过 程 如 下 所 示 。 





public static void main(String[] args) { 


Process.setArgV0("<pre-initialized>"); 
Looper .prepareMainLooper(); 
ActivityThread thread = new ActivityThread(); 
thread.attach(false); 
if (sMainThreadHandler == null) { 
sMainThreadHandler = thread.getHandler(); 
j 
AsyncTask.init(); 
if (false) { 
Looper .myLooper().setMessageLogging(new LogPrinte 
J 
Looper.loop(); 


throw new RuntimeException("Main thread loop unexpectedly 


主线 程 的 消息 循环 开始 了 以 后 ，ActivityThread 还 需要 一 个 Handler 
来 和 消息 队列 进行 交互 ， 这 个 Handler 束 是 ActivityIhread.H， 它 内 部 定 


义 了 一 组 消 轧 类 型 ， 主 要 包含 了 四 大 组 件 的 局 动 和 停止 等 过 程 ， 如 下 所 


ZN o 


private class H extends 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


public static final 


ActivityThread 通 过 ApplicationThread 和 AMS 进 行进 程 间 通信 ， 








Handler { 


int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 


int 


LAUNCH_ACTIVITY 
PAUSE_ACTIVITY 
PAUSE_ACTIVITY_FINISHING 
STOP_ACTIVITY_SHOW 
STOP_ACTIVITY_HIDE 
SHOW_WINDOW 
HIDE_WINDOW 
RESUME_ACTIVITY 
SEND_RESULT 
DESTROY_ACTIVITY 
BIND_APPLICATION 
EXIT_APPLICATION 
NEW_INTENT 
RECEIVER 
CREATE_SERVICE 
SERVICE_ARGS 
STOP_SERVICE 


AMS 


以 进程 间 通 信 的 方式 完成 ActivityThread 的 请 求 后 会 回调 
ApplicationThread 中 的 Binder 方 法 ， 然 后 ApplicationThread 会 同 H 发 送 消 


息 ，H 收 到 消息 后 会 将 ApplicationThread 中 的 逻辑 切换 到 ActivityThread 


中 去 执行 ， 即 切换 到 主线 程 中 去 执行 ， 这 个 过 程 就 是 主线 程 的 消 妃 循环 
模型 。 


第 11 草 ”Android 的 线程 和 线程 池 


本 章 的 主题 是 Android 中 的 线程 和 线程 池 。 线 程 在 Android 中 是 一 个 
很 重要 的 概念 ， 从 用 途上 来 说 ， 线 程 分 为 主线 程 和 子 线程 ， 主 线程 主要 
处 理 和 界面 相关 的 事情 ， 而 子 线程 则 往往 用 于 执行 耗 时 操作 。 由 于 
Android 的 特性 ， 如 果 在 主线 程 中 执行 耗 时 操作 那么 就 会 叶 致 程序 无 法 
及 时 地 啊 应 ， 因 此 耗 时 操作 必须 放 在 子 线程 中 去 执行 。 除 了 Thread 本 号 
以 外 ， 在 Android 中 可 以 扮演 线程 角色 的 还 有 很 多 ， 比 如 AsyncTask 和 
IntentService， 同 时 HandlerThread 也 是 一 种 特殊 的 线程 。 尽 管 
AsyncTask、IntentService 以 及 HandlerThread 的 表现 形式 都 有 别 于 传统 的 
线程 ， 但 是 它们 的 本 质 仍然 是 传统 的 线程 。 对 于 AsyncTask 来 说 ， 它 的 
底层 用 到 了 线程 池 ， 对 于 IntentService 和 HandlerThread 来 说 ， 它 们 的 底 
层 则 直接 使 用 了 线程 。 











不 同形 式 的 线程 虽然 都 是 线程 ， 但 是 它们 仍然 具有 不 同 的 特性 和 使 
用 场景 。AsyncTask 封 装 了 线程 池 和 Handler， 它 主要 是 为 了 方便 开发 者 
在 子 线程 中 更 新 UI。HandlerThread 是 一 种 具有 消息 循环 的 线程 ， 在 它 的 
内 部 可 以 使 用 Handler。IntentService 是 一 个 服务 ， 系 统 对 其 进行 了 封装 
使 其 可 以 更 方便 地 执行 后 台 任 务 ，IntentService 内 部 采用 HandlerThread 
来 执行 任务 ， 当 任务 执行 完毕 后 IntentService 会 自动 退出 。 从 任务 执行 
的 角度 来 看 ，IntentService 的 作用 很 像 一 个 后 台 线 程 ， 但 是 IntentService 
是 一 种 服务 ， 它 不 容易 被 系统 杀 死 从 而 可 以 尽量 保证 任务 的 执行 ， 而 如 
果 是 一 个 后 台 线 程 ， 由 于 这 个 时 候 进 程 中 没有 活动 的 四 大 组 件 ， 那 么 这 
个 进程 的 优先 级 就 会 非常 低 ， 会 很 容易 被 系统 杀 死 ， 这 就 是 








IntentService 的 优点 。 


在 操作 系统 中 ， 线 程 是 操作 系统 调度 的 最 小 单元 ， 同 时 线程 又 是 一 
种 受 限 的 系统 资源 ， 即 线程 不 可 能 无 限制 地 产生 ， 并 且 线 程 的 创建 和 销 
毁 都 会 有 相应 的 开销 。 当 系统 中 存在 大 量 的 线程 时 ， 系 统 会 通过 时 间 厂 
轮转 的 方式 调度 每 个 线程 ， 因 此 线程 不 可 能 做 到 绝对 的 并 行 ， 除 非 线 程 
数量 小 于 等 于 CPU 的 核心 数 ， 一 般 来 说 这 是 不 可 能 的 。 试 想 一 下 ， 如 果 
在 一 个 进程 中 频 芝 地 创建 和 销毁 线程 ， 这 显然 不 是 高 效 的 做 法 。 正 确 的 
做 法 是 采用 线程 池 ， 一 个 线程 池 中 会 缓存 一 定数 量 的 线程 ， 通 过 线程 池 
就 可 以 避免 因为 频 索 创建 和 销毁 线程 所 带 来 的 系统 开销 。Android 中 的 
线程 池 来 源 于 Java， 主 要 是 通过 Executor 来 派生 特定 类 型 的 线程 池 ， 不 
同 种 类 的 线程 池 又 具有 各 自 的 特性 ， 详 细 内 容 会 在 11.3 节 中 进行 介绍 。 











11.1 主线 程 和 子 线程 


主线 程 是 指 进程 所 拥有 的 线程 ， 在 Java 中 默认 情况 下 一 个 进程 只 有 
一 个 线程 ， 这 个 线程 就 是 主线 程 。 主 线程 主要 处 理 界 面 交 互相 关 的 逻 
辑 ， 因 为 用 户 随 时 会 和 界面 发 生 交 互 ， 因 此 主线 程 在 任何 时 候 都 必须 有 
较 高 的 啊 应 速度 ， 人 否则 就 会 产生 一 种 界面 卡 顿 的 感 党 。 为 了 保持 较 高 的 
响应 速度 ， 这 就 要 求 主线 程 中 不 能 执行 耗 时 的 任务 ， 这 个 时 候 子 线程 束 
派 上 用 场 了 。 子 线程 也 叫 工作 线程 ， 除 了 主线 程 以 外 的 线程 都 是 子 线 


程 。 























Android 沿 用 了 Java 的 线程 模型 ， 其 中 的 线程 也 分 为 主线 程 和 子 线 
程 ， 其 中 主线 程 也 叫 UI 线 程 。 主 线程 的 作用 是 运行 四 大 组 件 以 及 处 理 它 
们 和 用 户 的 交互 ， 而 子 线程 的 作用 则 是 执行 耗 时 任务 ， 比 如 网 络 请 求 、 
IO 操作 等 。 从 Android 3.0 开 始 系统 要 求 网 络 访问 必须 在 子 线程 中 进行 ， 
否则 网 络 访问 将 会 失败 并 抛 出 NetworkOnMainThreadException 这 个 异 
党 ， 这 样 做 是 为 了 避免 主线 程 由 于 被 耗 时 操作 所 阻 寨 从 而 出 现 ANR 现 
象 。 





11.2 Android 中 的 线程 形态 


本 节 将 对 Android 中 的 线程 形态 做 一 个 全 面 的 介绍 ， 除 了 传统 的 
Thread 以 外 ， 还 包含 AsyncTask、HandlerThread 以 及 IntentService， 这 三 
者 的 底层 实现 也 是 线程 ， 但 是 它们 有 具有 特殊 的 表现 形式 ， 同 时 在 使 用 上 
也 各 有 优 缺 点 。 为 了 简化 在 子 线程 中 访问 UI 的 过 程 ， 系 统 提供 了 
AsyncTask，AsyncTask 经 过 几 次 修改 ， 导 致 了 对 于 不 同 的 API 版 本 
AsyncTask 具 有 不 同 的 表现 ， 尤 其 是 多 任务 的 并 发 执行 上 。 由 于 这 个 原 
因 ， 很 多 开发 者 对 AsyncTask 的 使 用 上 存在 误区 ， 本 市 将 详细 介 ei 
AsyncTask 时 的 注意 事项 ， 并 从 源码 的 角度 来 分 析 AsyncTask 的 执行 

程 。 








11.2.1 AsyncTask 


AsyncTask 是 一 种 轻 量 级 的 异步 任务 类 ， 它 可 以 在 线程 池 中 执行 后 
台 任 务 ， 然 后 把 执行 的 进度 和 最 终结 果 传 递 给 主线 程 并 在 主线 程 中 更 新 
UI。 从 实现 上 来 次 ，AsyncTask 封 装 了 Thread 和 Handler， 通 过 AsyncTask 
可 以 更 加 方便 地 执行 后 台 任 务 以 及 在 主线 程 中 访问 UI， 但 是 AsyncTask 
并 不 适合 进行 特别 耗 时 的 后 台 任务 ， 对 于 特别 耗 时 的 任务 来 说 ， 建 议 使 
用 线程 池 。 


AsyncTask 是 一 个 抽象 的 泛 型 类 ， 它 提供 了 Params、Progress 和 
Result 这 三 个 泛 型 参数 ， 其 中 Params 表 示 参 数 的 类 型 ，Progress 表 示 后 合 
任务 的 执行 进度 的 类 型 ， 而 Result 则 表示 后 台 任 务 的 返回 结果 的 类 型 ， 
如 有 果 AsyncTask 确 实 不 需要 传递 具体 的 参数 ， 那 么 这 三 个 泛 型 参数 可 以 


用 Void 来 代替 。AsyncTask 这 个 类 的 声明 如 下 所 示 。 


public abstract class AsyncTask<Params, Progress,Result>. 
AsyncTask 提 供 了 4 个 核心 方法 ， 它 们 的 含义 如 下 所 示 。 


(1) onPreExecute()， 在 主线 程 中 执行 ， 在 异步 任务 执行 之 前 ， 此 
方法 会 被 调用 ， 一般 可 以 用 于 做 一 些 准备 工作 。 


(2) doInBackground(Params...params)， 在 线程 池 中 执行 ， 此 方法 
用 于 执行 异步 任务 ，params 参 数 表 示 异 步 任务 的 输入 参数 。 在 此 方法 中 
可 以 通过 publishProgress 方 法 来 更 新 任务 的 进度 ，publishProgress 方 法 会 
调用 onProgressUpdate 方 法 。 另 外 此 方法 需要 返回 计算 结果 给 
onPostExecute 方 法 。 


(3) onProgressUpdate(Progress...values)， 在 主线 程 中 执行 ， 当 后 
台 任 务 的 执行 进度 发 生 改 变 时 此 方法 会 被 调用 。 


(4) onPostExecute(Result result)， 在 主线 程 中 执行 ， 在 异步 任务 执 
行 之 后 ， 此 方法 会 被 调用 ， 其 中 result 参 数 是 后 台 任 务 的 返回 值 ， 即 
doInBackground 的 返回 值 。 


上 面 这 几 个 方法 ，onPreExecute 先 执行 ， 接 着 是 doInBackground,， 
最 后 才 是 onPostExecute。 除 了 上 述 四 个 方法 以 外 ，AsyncTask 还 提供 了 
onCancelled() 方 法 ， 它 同样 在 主线 程 中 执行 ， 当 异步 任务 被 取消 时 ， 
onCancelled() 方 法 会 被 调用 ， 这 个 时 候 onPostExecute 则 不 会 被 调用 。 下 
面 提供 一 个 典型 的 示例 ， 如 下 所 示 。 


private class DownloadFilesTask extends AsyncTask<URL, Integer 


protected Long doInBackground(URL... urls) { 





在 上 面 的 代码 中 ， 实 现 了 一 个 具体 的 AsyncTask 类 ， 这 个 类 主要 用 
于 模拟 文件 的 下 载 过 程 ， 它 的 输入 参数 类 型 为 URL， 后 台 任 务 的 进程 参 
数 为 Integer， 而 后 台 任 务 的 返回 结果 为 Long 类 型 。 注 意 到 
doInBackground 和 onProgressUpdate 方 法 它们 的 参数 中 均 包 含 ... 的 字样 ， 
在 Java 中 ... 表 示 参 数 的 数量 不 定 ， 它 是 一 种 数组 型 参数 ，... 的 概念 和 C 
语言 中 的 ... 是 一 致 的 。 当 要 执行 上 述 下 载 任 务 时 ， 可 以 通过 如 下 方式 来 


完成 : 


new DownloadFilesTask().execute(url1,url2,ur13); 


在 DownloadFilesTask 中 ，doInBackground 用 来 执行 具体 的 下 载 任务 
并 通过 publishProgress 方 法 来 更 新 下 载 的 进度 ， 同 时 还 要 判断 下 载 任务 
是 否 被 外 界 取 消 了 。 当 下 载 任 务 完 成 后 ，doInBackground 会 返回 结果 ， 
即 下 载 的 总 字 节 数 。 需 要 注意 的 是 ，doInBackground 是 在 线程 池 中 执行 
的 。onProgressUpdate 用 于 更 新 界面 中 下 载 的 进度 ， 它 运行 在 主线 程 ， 
当 publishProgress 被 调用 时 ， 此 方法 就 会 被 调用 。 当 下 载 任 务 完 成 后 ， 
onPostExecute 方 法 就 会 被 调 用 ， 它 也 是 运行 在 主线 程 中 ， 这 个 时 候 我 们 
就 可 以 在 界面 上 做 出 一 些 提示 ， 比 如 弹出 一 个 对 话 框 告知 用 户 下 载 已 经 
完成 














AsyncTask 在 具体 的 使 用 过 程 中 也 是 有 一 些 条 件 限制 的 ， 主 要 有 如 
RIL: 





(1) AsyncTask 的 类 必须 在 主线 程 中 加 载 ， 这 就 意味 着 第 一 次 访问 
AsyncTask 必 须发 生 在 主线 程 ， 当 然 这 个 过 程 在 Android 4.1 及 以 上 版 本 
中 已 经 被 系统 自动 完成 。 在 Android 5.0 的 源码 中 ， 可 以 查看 
ActivityThread 的 main 方 法 ， 它 会 调用 AsyncTask 的 init 方 法 ， 这 就 满足 了 
AsyncTask 的 类 必须 在 主线 程 中 进行 加 载 这 个 条 件 了 。 至 于 为 什么 必须 
要 满足 这 个 条 件 ， 在 11.2.2 节 中 会 结合 AsyncTask 的 源码 再 次 分 析 这 个 问 
题 。 











(2) AsyncTask 的 对 象 必须 在 主线 程 中 创建 。 


(3) execute 方 法 必须 在 UI 线程 调用 。 





(4) 不 要 在 程序 中 直接 调用 onPreExecute()、onPostExecute、 
doInBackground 和 onProgressUpdate 方 法 。 


(5) 一 个 AsyncTask 对 象 只 能 执行 一 次 ， 即 只 能 调用 一 次 execute 方 
法 ， 人 否则 会 报 运行 时 异 销 。 





(6) 在 Android 1.6 之 前 ，AsyncTask 是 串 行 执行 任务 的 ，Android 
1.6 的 时 候 AsyncTask 开 始 采用 线程 池 里 处 理 并 行 任 务 ， 但 是 从 Android 
3.0 开 始 ， 为 了 避免 AsyncTask 所 带 来 的 并 发 错误 ，AsyncTask 又 采用 一 
个 线程 来 串 行 执 行 任务 。 尽 管 如 此 ， 在 Android 3.0 以 及 后 续 的 版 本 中 ， 
我 们 仍然 可 以 通过 AsyncTask 的 executeOnExecutor 方 法 来 并 行 地 执行 任 
务 。 





11.2.2 ”AsyncTask 的 工作 原理 


为 了 分 析 AsyncTask 的 工作 原理 ， 我 们 从 它 的 execute 方 法 开始 分 
析 ，execute 方 法 又 会 调用 executeOnExecutor 方 法 ， 它 们 的 实现 如 下 所 
示 。 


public final AsyncTask<Params,Progress,Result> execute(Params 
return executeOnExecutor (sDefaultExecutor, params); 
} 
public final AsyncTask<Params,Progress,Result> executeOnExecu 
Params... params) { 
if (mStatus != Status.PENDING) { 
switch (mStatus) { 
case RUNNING: 
throw new IllegalStateException(" 
+ " the task is a 


case FINISHED: 


throw new IllegalStateException(" 
+ " the task has 


+ "(a task can be 


} 
mStatus = Status.RUNNING; 


onPreExecute(); 
mworker.mParams = params; 
exec.execute(mFuture); 


return this; 


在 上 面 的 代码 中 ，sDefaultExecutor 实 际 上 是 一 个 串 行 的 线程 池 ， 
个 进程 中 所 有 的 AsyncTask 全 部 在 这 个 串 行 的 线程 池 中 排队 执行 ， 这 个 
排队 执行 的 过 程 后 面 会 再 进行 分 析 。 在 executeOnExecutor 方 法 中 ， 
AsyncTask 的 onPreExecute 方 法 最 先 执行 ， 然 后 线程 池 开 始 执行 。 下 面 分 
析 线 程 池 的 执行 过 程 ， 如 下 所 示 。 








public static final Executor SERIAL_EXECUTOR = new SerialExec 
private static volatile Executor sDefaultExecutor = SERIAL_EX 
private static class SerialExecutor implements Executor { 
final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnab 
Runnable mActive; 
public synchronized void execute(final Runnable r) { 
mTasks.offer(new Runnable() { 


public void run() { 


try { 


r.run(); 
} finally { 


scheduleNext(); 


t); 
if (mActive == null) { 


scheduleNext(); 


| 
protected synchronized void scheduleNext() { 
if ((mActive = mTasks.poll()) != null) { 


THREAD_POOL_EXECUTOR.execute(mActive) ; 


} 


从 SerialExecutor 的 实现 可 以 分 析 AsyncTask 的 排队 执行 的 过 程 。 首 
先 系 统 会 把 AsyncTask 的 Params 参 数 封装 为 FutureTask 对 象 ，FutureTask 
是 一 个 并 发 类 ， 在 这 里 它 充 当 了 Runnable 的 作用 。 接 着 这 个 FutureTask 
会 交 给 SerialExecutor 的 execute 方 法 去 处 理 ，SerialExecutor 的 execute 方 法 
首先 会 把 FutureTask 对 象 插入 到 任务 队列 mTasks 中 ， 如 果 这 个 时 候 没 有 
正在 活动 的 AsyncTask 任 务 ， 那 么 就 会 调用 SerialExecutor 的 scheduleNext 
方法 来 执行 下 一 个 AsyncTask 任 务 。 同 时 当 一 个 AsyncTask 任 务 执行 完 
后 ，AsyncTask 会 继续 执行 其 他 任务 直到 所 有 的 任务 都 被 执行 为 止 ， 从 
这 一 点 可 以 看 出 ， 在 默认 情况 下 ，AsyncTask 是 串 行 执行 的 。 


AsyncTask 中 有 两 个 线程 池 〈SerialExecutor 和 
THREAD POOL EXECUTOR ) 和 一 个 Handler (InternalHandler) ， 其 
中 线程 池 SerialExecutor 用 于 任务 的 排队 ， 而 线程 池 
THREAD_POOL_EXECUTOR 用 于 真正 地 执行 任务 ，InternalHandler 用 
于 将 执行 环境 从 线程 池 切 换 到 主线 程 ， 关 于 线程 池 的 概念 将 在 第 11.3 节 
中 详细 介绍 ， 其 本 质 仍 然 是 线程 的 调用 过 程 。 在 AsyncTask 的 构造 方法 
中 有 如 下 这 么 一 段 代 码 ， 由 于 FutureTask 的 run 方 法 会 调用 mWorker 的 call 
方法 ， 因 此 mWorker 的 call 方 法 最 终 会 在 线程 池 中 执行 。 





mworker = new WorkerRunnable<Params,Result>() { 
public Result call() throws Exception { 
mTaskInvoked.set(true); 
Process.setThreadPriority(Process.THREAD_PRIORITY 
//noinspection unchecked 


return postResult(doInBackground(mParams ) ); 
ti 
在 mWorker 的 call 方 法 中 ， 首 先 将 mTaskInvoked 设 为 tue， 表 示 当 前 


任务 已 经 被 调用 过 了 ， 然 后 执行 AsyncTask 的 doInBackground 方 法 ， 接 
着 将 其 返回 值 传 递 给 postResult 方 法 ， 它 的 实现 如 下 所 示 。 





private Result postResult(Result result) { 
@SuppressWarnings("unchecked" ) 
Message message = sHandler.obtainMessage(MESSAGE_POST_RES 
message.sendTotarget(); 


return result; 


在 上 面 的 代码 中 ， Bou 通过 sHandler 发 送 一 个 
MESSAGE_POST_RESULT 的 消息 ， 这 个 sSHandler 的 定义 如 下 所 示 。 


private static final InternalHandler sHandler = new InternalH 
private static class InternalHandler extends Handler { 
@SuppressWarnings({"unchecked", "RawUseOfParameterizedType 
@Override 
public void handleMessage(Message msg) { 
AsyncTaskResult result = (AsyncTaskResult) msg.ob 
switch (msg.what) { 
case MESSAGE _POST_RESULT: 
// There is only one result 
result.mTask.finish(result.mData[ 
break; 
case MESSAGE _POST_PROGRESS: 
result .mTask.onProgressUpdate(res 


break; 


可 以 发 现 ，sHandler 是 一 个 静态 的 Handler 对 象 ， 为 了 能 够 将 执行 环 
境 切 换 到 主线 程 ， 这 就 要 求 SHandler 这 个 对 象 必 须 在 主线 程 中 创建 。 由 
于 静态 成 员 会 在 加 载 类 的 时 候 进行 初始 化 ， 因 此 这 就 变相 要 求 
AsyncTask 的 类 必须 在 主线 程 中 加 载 ， 人 否则 同一 个 进程 中 的 AsyncTask 都 
将 无 法 正常 工作 。sHandler 收 到 MESSAGE_POST_RESULT 这 个 消息 后 
会 调用 AsyncTask 的 finish 方 法 ， 如 下 所 示 。 


private void finish(Result result) { 
if (isCancelled()) { 
onCancelled(result); 
} else { 
onPostExecute(result); 
t 
mStatus = Status.FINISHED; 


} 


AsyncTask 的 finish 方 法 的 逻辑 比较 简单 ， 如 果 AsyncTask 被 取消 执 
行 了 ， 那 么 束 调 用 onCancelled 方 法 ， 否 则 就 会 调用 onPostExecute 方 法 ， 
可 以 看 到 doInBackground 的 返回 结果 会 传递 给 onPostExecute 方 法 ， 到 这 
里 AsyncTask 的 整个 工作 过 程 束 分 析 完 毕 了 。 


通过 分 析 AsyncTask 的 源码 ， 可 以 进一步 确定 ， 从 Android 3.0 开 
台 ， 默 认 情 况 下 AsyncTask 的 确 是 串 行 执行 的 ， 在 这 里 通过 一 系列 实验 
来 证 实 这 个 判断 。 


请 看 如 下 实验 代码 ， 代 码 很 简单 ， 就 是 单 击 按钮 的 时 候 同 时 执行 5 
个 AsyncTask 任 务 ， 每 个 AsyncTask 会 休 虐 3s 来 模拟 耗 时 操作 ， 同 时 把 每 
个 AsyncTask 执 行 结束 的 时 间 打 印 出 来 ， 这 样 我 们 就 能 观察 出 AsyncTask 
到 撒 是 串 行 执行 还 是 并 行 执 行 。 





@Override 
public void onClick(View v) { 
if (v == mButton) { 
new MyAsyncTask("AsyncTask#1").execute(""); 


new MyAsyncTask("AsyncTask#2").execute(""); 














4y All FE Android 4.1.14 Android 2.3.3 的 设备 上 运行 程序 ， 按 照 本 节 前 
面 的 描述 ，AsyncTask 在 4.1.1 上 应 该 是 串 行 的 ， 在 2.3.3 上 应 该 是 并 行 
的 ， 到 底 是 不 是 这 样 呢 ? 请 看 下 面 的 运行 结果 。 





Android 4.1.1 上 执行 : 如 图 11-1 所 示 ，5 个 AsyncTask 共 耗 时 15s 且 时 
间 间 隔 为 3s8， 很 显然 是 串 行 执行 的 。 





Application 





图 11-1 AsyncTask 在 Android 4.1.1 上 的 执行 顺序 


Android 2.3.3 上 执行 : 如 图 11-2 所 示 ，5 个 AsyncTask 的 结束 时 间 是 
一 样 的， 很 显然 是 并 行 执行 的 。 
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图 11-2 AsyncTask 在 Android 2. 3.3 上 的 执行 顺序 


为 了 让 AsyncTask 可 以 在 Android 3.0 及 以 上 的 版 本 上 并 行 ， 可 以 采 
用 AsyncTask 的 executeOnExecutor 方 法 ， 需 要 注意 的 是 这 个 方法 是 
Android 3.0 新 添加 的 方法 ， 并 不 能 在 低 版 本 上 使 用 ， 如 下 上 所 示 。 





@TargetApi(Build.VERSION_CODES.HONEYCOMB) 
@Override 
public void onClick(View v) { 


if (v == mButton) { 


if (Build.VERSION.SDK_INT => Build.VERSION_CODES. 

new MyAsyncTask("AsyncTask#1"). 
executeOnExecutor (AsyncTask.THREAD_POOL_EXECUTOR, ""); 

new MyAsyncTask("AsyncTask#2"). 
executeOnExecutor (AsyncTask.THREAD_POOL_EXECUTOR, ""); 

new MyAsyncTask("AsyncTask#3"). 
executeOnExecutor (AsyncTask.THREAD_POOL_EXECUTOR, ""); 

new MyAsyncTask("AsyncTask#4"). 
executeOnExecutor (AsyncTask.THREAD_POOL_EXECUTOR, ""); 

new MyAsyncTask("AsyncTask#5"). 


executeOnExecutor (AsyncTask.THREAD_POOL_EXECUTOR, ""); 
i 


} 


private static class MyAsyncTask extends AsyncTask<String, Int 
private String mName = "AsyncTask"; 
public MyAsyncTask(String name) { 
super (); 
mName = name; 
Í 
@Override 
protected String doInBackground(String... params) { 
try { 
Thread.sleep(3000); 
} catch (InterruptedException e) { 


e.printStackTrace(); 


return mName; 
} 
@Override 
protected void onPostExecute(String result) { 
super .onPostExecute(result); 
SimpleDateFormat df = new SimpleDateFormat("yyyy- 


Log.e(TAG, result + "execute finish at " + df.form 


} 


在 Android 4.1.1 的 设备 上 运行 上 述 程序 ， 日 志 如 图 11-3 所 示 ， 很 显 
然 ， 我 们 的 目的 达到 了 ， 成 功 地 让 AsyncTask 在 4.1.1 的 手机 上 并 行 起 来 
Ta 
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图 11-3 AsyncTask 的 execute0nExecutor 方 法 的 作用 


11.2.3 HandlerThread 


HandlerThread 继 承 了 Thread， 它 是 一 种 可 以 使 用 Handler 的 Thread,， 
它 的 实现 也 很 简单 ， 就 是 在 run 方 法 中 通过 Looper.prepare() 来 创建 消息 队 
列 ， 并 通过 Looper.loop() 来 开局 消息 循环 ， 这 样 在 实际 的 使 用 中 就 允许 
在 HandlerThread 中 创建 Handler 了 。HandlerThread 的 run 方 法 如 下 所 示 。 





public void run() { 


mTid = Process.myTid()j; 
Looper.prepare(); 
synchronized (this) { 
mLooper = Looper.myLooper()j; 
notifyAll(); 
i 
Process.setThreadPriority(mPriority); 
onLooperPrepared(); 
Looper.loop(); 
mTid = -1; 
Í 


从 HandlerThread 的 实现 来 看 ， 它 和 普通 的 Thread 有 显著 的 不 同 之 
处 。 普 通 Thread 主 要 用 于 在 run 方 法 中 smn i 而 
HandlerThread 在 内 部 创建 了 消息 队列 ， 外 界 需 过 Handler 的 消息 方 
式 来 通知 HandlerThread 执 行 一 个 具体 的 任务 。 eee ica ie 
用 的 类 ， 它 在 Android 中 的 的 使 用 场景 是 IntentService， 
IntentS a 11.2.4 节 中 进行 介绍 。 由 于 HandlerThread 的 run 方 法 是 
一 个 无 限 循环 ， 因 此 当 明 确 不 需要 再 使 用 HandlerThread 时 ， 可 以 通过 它 
的 quit 或 者 quitSafely 方 法 来 终止 线程 的 执行 ， 这 是 一 个 良好 的 编程 习 
惯 。 








11.2.4 IntentService 


IntentService 是 一 种 特殊 的 Service， 它 继承 了 Service 并 且 它 是 一 个 
抽象 类 ， 因 此 必须 创建 它 的 子 类 才能 使 用 IntentService。IntentService 可 


用 于 执行 后 台 耗 时 的 任务 ， 当 任务 执行 后 它 会 自动 停止 ， 同 时 由 于 
IntentService 是 服务 的 原因 ， 这 导致 它 的 优先 级 比 单纯 的 线程 要 高 很 
多 ， 所 以 IntentService 比 较 适 合 执行 一 些 高 优先 级 的 后 台 任务 ， 因 为 它 
优先 级 高 不 容易 被 系统 杀 死 。 在 实现 上 ，ntentService 封 装 了 
HandlerThread 和 Handler， 这 一 点 可 以 从 它 的 onCreate 方 法 中 看 出 来 ， 如 
下 所 示 。 





public void onCreate() { 
// TODO: It would be nice to have an option to hold a par 
// during processing,and to have a static startService(Co 
// method that would launch the service & hand off a wake 
super.onCreate(); 
HandlerThread thread = new HandlerThread("IntentService[" 
thread.start(); 
mServiceLooper = thread.getLooper(); 


mServiceHandler = new ServiceHandler(mServiceLooper ) ; 


当 IntentService 被 第 一 次 启动 时 ， 它 的 onCreate 方 法 会 被 调用 ， 
onCreate 方 法 会 创建 一 个 HandlerThread， 然 后 使 用 它 的 Looper 来 构造 一 
个 Handler 对 象 mServiceHandler， 这 样 通过 mServiceHandler 友 送 的 消息 
最 终 都 会 在 HandlerThread 中 执行 ， 从 这 个 角度 来 看 ，IntentService 也 可 
以 用 于 执行 后 台 任务 。 每 次 启动 IntentService， 它 的 onStartCommand 方 
法 就 会 调用 一 次 ，IntentService 在 onStartCommand 中 处 理 每 个 后 台 任 务 
的 Pntent。 下 面 看 一 下 onStartCommand 方 法 是 如 何 处 理 外 界 的 Intent 的 ， 
onStartCommand 调 用 了 onStart，onStart 方 法 的 实现 如 下 所 示 。 


public void onStart(Intent intent,int startId) { 


Message msg = mServiceHandler.obtainMessage(); 
msg.argi = startId; 

msg.obj = intent; 
mServiceHandler.sendMessage(msg); 


} 


可 以 看 出 ，IntentService 仅 仅 是 通过 mServiceHandler 发 送 了 一 个 消 
息 ， 这 个 消息 会 在 HandlerThread 中 被 处 理 。mServiceHandler 收 到 消息 
后 ， 会 将 Intent 对 象 传递 给 onHandleIntent 方 法 去 处 理 。 注 意 这 个 Intent 对 
象 的 内 容 和 外 界 的 startService(intenbD 中 的 intent 的 内 容 是 完全 一 致 的 ， 通 
过 这 个 Intent 对 象 即 可 解析 出 外 界 局 动 IntentService 时 所 传递 的 参数 ， 通 
过 这 些 参数 就 可 以 区 分 具体 的 后 人 台 任 务 ， 这 样 在 onHandleIntent 方 法 中 
就 可 以 对 不 同 的 后 台 任 务 做 处 理 了 。 当 onHandleIntent 方 法 执行 结 
后 ，IntentService 会 通过 stopSelf(int start1d) 方 法 来 尝试 停止 服务 。 这 里 之 
所 以 采用 stopSelf(int startId) 而 不 是 stopSelfO 来 停止 服务 ， 那 是 因为 
stopSelfO 会 立刻 停止 服务 ， 而 这 个 时 候 可 能 还 有 其 他 消息 未 处 理 ， 
stopSelf(int startId) 则 会 等 等 所 有 的 消 妃 都 处 理 完毕 后 才 终 止 服务 。 一 般 
来 说 ，stopSelf(int startId) 在 尝试 停止 服务 之 前 会 判断 最 近 启 动 服务 的 次 
数 是 否 和 startId 相 等 ， 如 果 相 等 就 立刻 停止 服务 ， 不 相等 则 不 停止 服 
务 ， 这 个 策略 可 以 从 AMS 的 stopServiceToken 方 法 的 实现 中 找到 依据 ， 
读者 感 兴趣 的 话 可 以 自行 查看 源码 实现 。ServiceHandler 的 实现 如 下 所 
示 














fe) 


private final class ServiceHandler extends Handler { 
public ServiceHandler(Looper looper) { 


super (looper); 


@Override 
public void handleMessage(Message msg) { 
onHandleIntent((Intent )msg.obj); 


stopSelf(msg.arg1); 


} 


IntentService 的 onHandleIntent 方 法 是 一 个 抽象 方法 ， 它 需要 我 们 在 
子 类 中 实现 ， 它 的 作用 是 从 Intent 参 数 中 区 分 具体 的 任务 并 执行 这 些 任 
务 。 如 果 目 前 只 存在 一 个 后 台 任 务 ， 那 么 onHandleIntent 方 法 执行 完 这 
“MES Ja, stopSelf(int start1d) 束 会 直接 停止 服务 ， 如 果 目 前 存在 多 个 后 
台 任 务 ， 那 么 当 onHandleIntent 方 法 执行 完 最 后 一 个 任务 时 ，stopSelf(int 
startId) 才 会 直接 停止 服务 。 男 外 ， 由 于 每 执行 一 个 后 台 任 务 就 必须 启动 
一 次 IntentService， 而 IntentService 内 部 则 通过 消息 的 方式 癌 
HandlerThread 请 求 执行 任务 ，Handler 中 的 Looper 是 顺序 处 理 消息 的 ， 这 
就 意味 着 IntentService 也 是 顺序 执行 后 台 任 务 的 ， 当 有 多 个 后 台 任 务 同 
时 存在 时 ， 这 些 后 台 任 务 会 按照 外 界 发 起 的 顺序 排队 执行 。 











下 面 通过 一 个 示例 来 进一步 说 明 IntentService 的 工作 方式 ， 首 先 派 
和 牛 一 个 IntentService 的 子 类 ， 比 如 LocalIntentService， 它 的 实现 如 下 所 
ZN 


public class LocalIntentService extends IntentService { 
private static final String TAG = "LocalIntentService"; 
public LocalIntentService() { 
super (TAG); 
$ 


@Override 


protected void onHandleIntent(Intent intent) { 
String action = intent.getStringExtra("task_action") 
Log.d(TAG, "receive task :" + action); 
SystemClock.sleep( 3000) ; 
if ("com.ryg.action.TASK1".equals(action)) { 


Log.d(TAG, "handle task: " + action); 


I; 
@Override 
public void onDestroy() { 
Log.d(TAG, "Service destroyed."); 


super.onDestroy()j; 


这 里 对 LocalIntentService 的 实现 做 一 下 简单 的 说 明 。 在 
onHandleIntent 方 法 中 会 从 参数 中 解析 出 后 台 任 务 的 标识 ， 即 task_action 
字段 所 代表 的 内 容 ， 然 后 根据 不 同 的 任务 标识 来 执行 具体 的 后 全 任务 。 
这 里 为 了 简单 起 见 ， 直 接 通 过 SystemClock.sleep(3000) 来 休眠 3000 上 毫秒 
从 而 模拟 一 种 耗 时 的 后 台 任 务 ， 另 外 为 了 验证 IntentService 的 停止 时 
机 ， 这 里 在 onDestroy0 中 打印 了 一 名 日志。LocalIntentService 实 现 完成 
了 以 后 ， 就 可 以 在 外 界 请 求 执行 后 台 任 务 了 ， 在 下 面 的 代码 中 先后 发 起 
了 3 个 后 台 任 务 的 请 求 : 


Intent service = new Intent(this, LocalIntentService.class); 
service.putExtra("task_action", "com.ryg.action.TASK1i"); 


startService(service); 


service.putExtra("task_action", "com.ryg.action.TASK2"); 


startService(service); 


service.putExtra("task_action","com.ryg.action.TASK3" ); 


startService(service); 


运行 程序 ， 观 察 日 


05-17 17:08:23. 
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05-17 
05-17 
05-17 
05-17 


17 


17 


17 


17 


17 


:08:23. 
:08:26. 
:08:26. 
:08:29. 
108927 


186 
196 
199 
199 
192 
205 


Em 


志 ， 如 下 所 示 。 


E/dalvikvm(25793): threadid=11: calling ru 


D/LocalIntentService(25793): 
D/LocalIntentService(25793): 
D/LocalIntentService( 25793): 
D/LocalIntentService(25793) : 
D/LocalIntentService(25793): 


receive task 
handle task: 
receive task 
receive task 


service destr 


05-17 17:08:32.205 E/dalvikvm(25793): threadid=11: exiti 





从 上 上面 的 日 志 可 以 看 出 ， 三 个 后 台 任 务 是 排队 执行 的 ， 它 们 的 执行 
顺序 就 是 它们 发 起 请 求 对 的 顺序 ， 即 TASK1、TASK2、TASK3。 另 外 
一 点 就 是 当 TASK3 执 行 完 毕 后 ，LocalIntentService 才 真正 地 停止 ， 从 日 
志 中 可 以 看 出 LocalIntentService 执 行 了 onDestroy()， 这 也 意味 着 服务 正 


在 停止 。 


11.3 Android 中 的 线程 池 


提 到 线程 池 就 必须 先 说 一 下 线程 池 的 好 处 ， 相 信 读 者 部 有 所 体会 ， 
线程 池 的 优点 可 以 概括 为 以 下 三 点 : 


(1) 重用 线程 池 中 的 线程 ， 避 免 因 为 线程 的 创建 和 销毁 所 带 来 的 
性 能 开销 。 


(2) 能 有 效 控制 线程 池 的 最 大 并 发 数 ， 避 免 大 量 的 线程 之 间 因 互 
相 抢占 系统 资源 而 导致 的 阻塞 现象 。 


(3) 能 够 对 线程 进行 简单 的 管理 ， 并 提供 定时 执行 以 及 指定 间隔 
循环 执行 等 功能 。 


Android 中 的 线程 池 的 概念 来 源 于 Java 中 的 Executor，Executor 是 一 
个 接口 ， 真 正 的 线程 池 的 实现 为 ThreadPoolExecutor。 
ThreadPoolExecutor 提 供 了 一 系列 参数 来 配置 线程 池 ， 通 过 不 同 的 参数 
可 以 创建 不 同 的 线程 池 ， 从 线程 池 的 功能 特性 上 来 说 ，Android 的 线程 
池 主 要 分 为 4 类 ， 这 4 类 线程 池 可 以 通过 Executors 所 提供 的 工厂 方法 来 得 
到 ， 具 体会 在 11.3.2 节 中 进行 详细 介绍 。 由 于 Android 中 的 线程 池 都 是 直 
接 或 者 间接 通过 配置 ThreadPoolExecutor 来 实现 的 ， 因 此 在 介绍 它们 之 


前 需要 先 介 绍 ThreadPoolExecutor。 


11.3.1 ThreadPoolExecutor 


ThreadPoolExecutor 是 线程 池 的 真正 实现 ， 它 的 构造 方法 提供 了 一 


系列 参数 来 配置 线程 池 ， 下 面 介 绍 ThreadPoolExecutor 的 构造 方法 中 各 
个 参数 的 舍 义 ， 这 些 参 数 将 会 直接 影响 到 线程 池 的 功能 特性 ， 下 面 是 
ThreadPoolExecutor 的 一 个 比较 常用 的 构造 方法 。 


public ThreadPoolExecutor(int corePoolSize, int maximumPoolSiz 
long keepAliveT 
TimeUnit unit, 
BlockingQueue<R 


ThreadFactory t 


corePoolSize 


线程 池 的 核心 线程 数 ， 默 认 情 况 下 ， 核 心 线程 会 在 线程 池 中 一 直 存 
活 ， 即 使 它们 处 于 闲置 状态 。 如 果 将 ThreadPoolExecutor 的 
allowCoreThreadTimeOut 属 性 设置 为 tue， 那 么 闲置 的 核心 线程 在 等 待 新 
任务 到 来 时 会 有 超时 策略 ， 这 个 时 间 间 隔 由 keepAliveTime 所 指定 ， 当 
等 竺 时间 超过 keepAliveTime 所 指定 的 时 长 后 ， 核 心 线程 就 会 被 终止 。 


maximumPoolSize 


线程 池 所 能 容纳 的 最 大 线程 数 ， 当 活动 线程 数 达 到 这 个 数值 后 ， 后 
续 的 新 任务 将 会 被 阻 窄 。 


keepAliveTime 


非 核 心 线程 困 置 时 的 超时 时 长 ， 超 过 这 个 时 长 ， 非 核心 线程 就 会 被 
回收 。 当 ThreadPool-Executor 的 allowCoreThreadTimeOnut 属 性 设置 为 true 
时 ，keepAliveTime 同 样 会 作用 于 核心 线程 。 


unit 


H THE keepAliveTime2 A Hy IN [A] AL, ee —-S AS, AYALA 
有 TimeUnit. MILLISECONDS 〈 毫 秒 ) ~ TimeUnit'SECONDS ( 秒 ) 以 
及 TimeUnit.MINUTES (分 钟 ) 等 。 


workQueue 


线程 池 中 的 任务 队列 ， 通 过 线程 池 的 execute 方 法 提交 的 Runnable 对 
象 会 存储 在 这 个 参数 中 。 


threadFactory 


线程 工厂 ， 为 线程 池 提供 创建 新 线程 的 功能 。ThreadFactory 是 一 个 
接口 ， 它 只 有 一 个 方法 : Thread newThread(Runnable r). 





除了 上 面 的 这 些 主要 参数 外 ，ThreadPoolExecutor 还 有 一 个 不 常用 
的 参数 Rejected-ExecutionHandler handler。 当 线程 池 无 法 执行 新 任务 
时 ， 这 可 能 是 由 于 任务 队列 已 满 或 者 是 无 法 成 功 执行 任务 ， 这 个 时 候 
ThreadPoolExecutor 会 调用 handler 的 rejectedExecution 方 法 来 通知 调用 
者 ， 默 认 情 况 下 rejectedExecution 方 法 会 直接 抛 出 一 个 RejectedExecution- 
Exception。ThreadPoolExecutor 为 RejectedExecutionHandler 提 供 了 几 个 可 
选 值 : CallerRunsPolicy、AbortPolicy、DiscardPolicy 和 
DiscardOldestPolicy， 其 中 AbortPolicy 是 默认 值 ， 它 会 mae 出 
RejectedExecutionException， 由 于 handler 这 个 参数 不 常用 ， 这 里 就 不 再 
具体 介绍 了 。 


ThreadPoolExecutor 执 行 任 务 时 大 致 遵循 如 下 规则 : 


(1) 如 果 线 程 池 中 的 线程 数量 未 达到 核心 线程 的 数量 ， 那 么 会 直 
接 启动 一 个 核心 线程 来 执行 任务 。 


(2) 如 果 线 程 池 中 的 线程 数量 已 经 达到 或 者 超过 核心 线程 的 数 
量 ， 那 么 任务 会 被 插入 到 任务 队列 中 排队 等 每 执行 。 


(3) 如 果 在 步骤 2 中 无 法 将 任务 插入 到 任务 队列 中 ， 这 往往 是 由 于 
任务 队列 已 满 ， 这 个 时 候 如 果 线 程 数 量 未 达到 线程 池 规 定 的 最 大 值 ， 那 
么 会 立刻 月 动 一 个 非 核心 线程 来 执行 任务 。 


(4) 如果 步骤 3 中 线程 数量 已 经 达到 线程 池 规 定 的 最 大 值 ， 那 么 就 
拒绝 执行 此 任务 ，ThreadPoolExecutor 会 调用 RejectedExecutionHandler 的 
rejectedExecution 方 法 来 通知 调 用 者 。 


ThreadPoolExecutor 的 参数 配置 在 AsyncTask 中 有 明显 的 体现 ， 下 面 
是 AsyncTask 中 的 线程 池 的 配置 情况 : 


private static final int CPU_COUNT = Runtime.getRuntime().ava 

private static final int CORE_POOL_SIZE = CPU_COUNT + 1; 

private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 + 

private static final int KEEP_ALIVE = 1; 

private static final ThreadFactory sThreadFactory = new Threa 
private final AtomicInteger mCount = new AtomicInteger(1) 
public Thread newThread(Runnable r) { 


return new Thread(r,"AsyncTask #" + mCount.getAnd 


}; 
private static final BlockingQueue<Runnable> sPoolWorkQueue = 
new LinkedBlockingQueue<Runnable>(128) ; 


jf ere 


* An {@link Executor} that can be used to execute tasks in 
we 
public static final Executor THREAD_POOL_EXECUTOR 


= new ThreadPoolExecutor(CORE_POOL_SIZE,MAXIMUM_P 


从 上 面 的 代码 可 以 知道 ，AsyncTask 对 
THREAD_POOL_EXECUTOR 这 个 线程 池 进 行 了 配置 ， 配 置 后 的 线程 池 
规格 如 下 : 





© 核心 线程 数 等 于 CPU 核心 数 +1; 

。 线程 池 的 最 大 线程 数 为 CPU 核心 数 的 2 倍 +1; 

。 核心 线程 无 超时 机 制 ， 非 核心 线程 在 闲置 时 的 超时 时 间 为 1 秒 ; 
。 任务 队列 的 容量 为 128。 


11.3.2 ”线程 池 的 分 类 


在 11.3.1 节 中 对 ThreadPoolExecutor 的 配置 细节 进行 了 详细 的 介绍 ， 
本 节 将 接着 介绍 Android 中 最 常见 的 四 类 具有 不 同 功能 特性 的 线程 池 ， 
它们 都 直接 或 间接 地 通过 配置 ThreadPoolExecutor 来 实现 自己 的 功能 特 
性 ， 这 四 类 线程 池 分 别 是 FixedThreadPool、CachedThreadPool、 
ScheduledThreadPool 以 及 SingleThreadExecutor。 





1. FixedThreadPool 


通过 Executors 的 newFixedThreadPool 方 法 来 创建 。 它 是 一 种 线程 数 
量 固定 的 线程 池 ， 当 线程 处 于 空闲 状态 时 ， 它 们 并 不 会 被 回收 ， 除 非 线 
程 池 被 关闭 了 。 当 所 有 的 线程 都 处 于 活动 状态 时 ， 新 任务 都 会 处 于 等 符 


状态 ， 直 到 有 线程 空闲 出 来 。 由 于 FixedThreadPool 只 有 核心 线程 并 且 这 
些 核心 线程 不 会 被 回 收 ， 这 意味 着 它 能 够 更 加 快速 地 响应 外 界 的 请 求 。 
newFixedThreadPool 方 法 的 实现 如 下 ， 可 以 发 现 FixedThreadPool 中 只 有 
核心 线程 并 且 这 些 核 心 线程 没有 超时 机 制 ， 另 外 任务 队列 也 是 没有 大 小 
限制 的 。 


public static ExecutorService newFixedThreadPool(int nThreads 


return new ThreadPoolExecutor(nThreads, nThreads, 


} 
2. CachedThreadPool 


通过 Executors 的 newCachedThreadPool 方 法 来 创建 。 它 是 一 种 线程 
数量 不 定 的 线程 池 ， 它 只 有 非 核心 线程 ， 并 且 其 最 大 线程 数 为 
Integer.MAX_VALUE。 由 于 Integer.MAX_VALUE 是 一 个 很 大 的 数 ， 实 
际 上 就 相当 于 最 大 线程 数 可 以 任意 大 。 当 线程 池 中 的 线程 都 处 于 活动 状 
态 时 ， 线 程 池 会 创建 新 的 线程 来 处 理 新 任务 ， 否 则 就 会 利用 空闲 的 线程 
来 处 理 新 任务 。 线 程 池 中 的 空间 线程 都 有 超时 机 制 ， 这 个 超时 时 长 为 60 
秒 ， 超 过 60 秒 闲置 线程 加 会 被 回收 。 和 FixedThreadPool 不 同 的 是 ， 
CachedThreadPool 的 任务 队列 其 实 相 当 于 一 个 空 集合 ， 这 将 导致 任何 任 
务 都 会 立即 被 执行 ， 因 为 在 这 种 场景 下 SynchronousQueue 是 无 法 插入 任 
务 的 。SynchronousQueue 是 一 个 非常 特殊 的 队列 ， 在 很 多 情况 下 可 以 把 
它 简 单 理解 为 一 个 无 法 存储 元 素 的 队列 ， 由 于 它 在 实际 中 较 少 使 用 ， 这 
里 就 不 深入 探讨 它 了 。 从 CachedThreadPool 的 特性 来 看 ， 这 类 线程 池 比 
较 适 合 执 行 大量 的 耗 时 较 少 的 任务 。 当 整个 线程 池 都 处 于 闲置 状态 时 ， 
线程 池 中 的 线程 都 会 超时 而 被 停止 ， 这 个 时 候 CachedThreadPool 之 中 实 

















际 上 是 没有 任何 线程 的 ， 它 几乎 是 不 占用 任何 系统 资源 的 。 
newCachedThreadPool 方 法 的 实现 如 下 所 示 。 


public static ExecutorService newCachedThreadPool() { 
return new ThreadPoolExecutor(0, Integer .MAX_VALUE, 
60L, TimeUnit.SECONDS, 


new SynchronousQueue<Runnabl 


3. ScheduledThreadPool 


通过 Executors 的 newScheduledThreadPool 方 法 来 创建 。 它 的 核心 线 
程 数量 是 固定 的 ， 而 非 核心 线程 数 是 没有 限制 的 ， 并 且 当 非 核心 线程 朵 
置 时 会 被 立即 回收 。ScheduledThreadPool 这 类 线程 池 主 要 用 于 执行 定时 
任务 和 具有 固定 周期 的 重复 任务 ，newScheduledThreadPool 方 法 的 实现 
如 下 所 示 。 











public static ScheduledExecutorService newScheduledThreadPool 
corePoolSize) { 
return new ScheduledThreadPoolExecutor(corePoolSize) ; 
t 
public ScheduledThreadPoolExecutor(int corePoolSize) { 
super (corePoolSize, Integer .MAX_VALUE, 0, NANOSECONDS, 


new DelayedworkQueue()); 


4. SingleThreadExecutor 


通过 Executors 的 newSingleThreadExecutor 方 法 来 创建 。 这 类 线程 池 


内 部 只 有 一 个 核心 线程 ， 它 确保 所 有 的 任务 都 在 同一 个 线程 中 按 顺 序 执 
行 。SingleThreadExecutor 的 意义 在 于 统一 所 有 的 外 界 任 务 到 一 个 线程 
中 ， 这 使 得 在 这 些 任务 之 间 不 需要 处 理 线程 同步 的 问题 。 
newSingleThreadExecutor 方 法 的 实现 如 下 所 示 。 











public static ExecutorService newSingleThreadExecutor() { 
return new FinalizableDelegatedExecutorService 
(new ThreadPoolExecutor(1,1, 
OL, TimeUnit .MILLISECONDS, 


new LinkedBlockingQueue<Ru 


上 面 对 Android 中 第 见 的 4 种 线程 池 进 行 了 详细 的 介绍 ， 除 了 上 面 系 
统 提供 的 4 类 线程 池 以 外 ， 也 可 以 根据 实际 需要 灵活 地 配置 线程 池 。 下 
面 的 代码 演示 了 系统 预 置 的 4 种 线程 池 的 典型 使 用 方法 。 








Runnable command = new Runnable() { 
@Override 
public void run() { 


SystemClock.sleep( 2000) ; 


}; 

ExecutorService fixedThreadPool = Executors.newFixedThreadPoo 
fixedThreadPool.execute(command) ; 

ExecutorService cachedThreadPool = Executors.newCachedThreadP 
cachedThreadPool.execute(command) ; 


ScheduledExecutorService scheduledThreadPool = Executors.newS 


// 2000ms 后 执行 command 


第 12 晶 Bitmap 的 加 载 和 Cache 


本 章 的 主题 是 Bitmap 的 加 载 和 Cache， 主 要 包含 三 个 方面 的 内 容 。 
首先 讲述 如 何 有 效 地 加 载 一 个 Bitmap， 这 是 一 个 很 有 意义 的 话题 ， 由 于 
Bitmap 的 特殊 性 以 及 Android 对 单个 应 用 所 施加 的 内 存 限 制 ， 比 如 
16MB， 这 导致 加 载 Bitmap 的 时 候 很 容易 出 现 内 存 洲 出 。 下 面 这 个 异常 
言 息 在 开发 中 应 该 时 常 遇 到 : 





java.lang.OutofMemoryError: bitmap size exceeds VM budget 





因此 如 何 高 效 地 加 载 Bitmap 是 一 个 很 重要 也 很 容易 被 开发 者 忽视 的 


问题 。 


接着 介绍 Android 中 第 用 的 缓存 策略 ， 绥 存 策略 是 一 个 通用 的 思 
想 ， 可 以 用 在 很 多 场景 中 ， 但 是 实际 开发 中 经 党 需要 用 Bitmap 做 绥 存 。 
通过 绥 存 策略 ， 我 们 不 需要 每 次 都 从 网 络 上 请 求 图 片 或 者 从 存储 设备 中 
加 载 图 片 ， 这 样 就 极 大 地 提高 了 图 片 的 加 载 效 紊 以 及 产品 的 用 户 体 验 。 
目前 比较 常用 的 缓存 策略 是 LruCache 和 DiskLruCache， 其 中 LruCache 常 
被 用 做 内 存 缓存 ， 而 DiskLruCache 常 被 用 做 存储 缓存 。Lru 是 Least 
Recently Used 的 缩写 ， 即 最 近 最 少 使 用 算法 ， 这 种 算法 的 核心 思想 为 : 
当 缓存 快 满 时 ， 会 淘汰 近期 最 少 使 用 的 缓存 目标 ， 很 显然 Lru 算 法 的 思 
想 是 很 容易 被 接受 的 。 











最 后 本 章 会 介绍 如 何 优 化 列表 的 卡 顿 现象 ，ListView 和 GridView 由 
于 要 加 载 大 量 的 子 视图 ， 当 用 户 快 速 滑动 时 就 容易 出 现 卡 顿 的 现象 ， 














此 本 章 最 后 针对 这 个 问题 将 会 给 出 一 些 优化 建议 。 


为 了 更 好 地 介绍 上 述 三 个 主题 ， 本 章 提 供 了 一 个 示例 程序 ， 该 程序 
会 尝试 从 网 络 加 载 大 量 图 片 并 在 GridView 中 显示 ， 可 以 发 现 这 个 程序 具 
有 很 强 的 实用 性 ， 并 且 其 技术 细节 完全 徐 盖 了 本 章 的 三 个 主题 ,图片 加 
载 、 绥 存 策略 、 列 表 的 滑动 流畅 性 ， 通 过 这 个 示例 程序 读者 可 以 很 好 地 
理解 本 章 的 全 部 内 容 并 能 够 在 实际 中 灵活 应 用 。 











12.1 Bitmap 的 高 效 加 载 


在 介绍 Bitmap 的 高 效 加 载 之 前 ， 先 说 一 下 如 何 加 载 一 个 Bitmap， 
Bitmap 在 Android 中 指 的 是 一 张 图 片 ， 可 以 是 png 格 式 也 可 以 是 jpg 等 其 他 
常 见 的 图 斤 格 式 。 那 么 如 何 加 载 一 个 图 乒 呢 ? BitmapFactory 类 提供 了 四 
类 方法 : decodeFile、decodeResource、decodeStream 和 
decodeByteArray， 分 别 用 于 文 持 从 文件 系统 、 资 源 、 输 入 流 以 及 字 节 数 
组 中 加 载 出 一 个 Bitmap 对 象 ， 其 中 decodeFile 和 decodeResource 又 间接 调 
用 了 decodeStream 方 法 ， 这 四 类 方法 最 终 是 在 Android 的 底层 实现 的 ， 对 
应 着 BitmapFactory 类 的 几 个 native 方 法 。 








如 何 高 效 地 加 载 Bitmap 呢 ? 其 实 核心 思想 也 很 简单 ， 那 融 是 采用 
BitmapFactory.Options 来 加 载 所 需 尺 寸 的 图 片 。 这 里 假设 通过 ImageView 
来 显示 图 片 ， 很 多 时 候 ImageView 并 没有 图 片 的 原始 尺寸 那么 大 ， 这 个 
时 候 把 整个 图 片 加 载 进 来 后 再 设 给 ImageView， 这 显然 是 没 必要 的 ， 
为 ImageView 并 没有 办 法 显示 原始 的 图 片 。 通 过 BitmapFactory.Options 束 
可 以 按 一 定 的 采样 率 来 加 载 缩小 后 的 图 片 ， 将 缩小 后 的 图 片 在 
ImageView 中 显示 ， 这 样 束 会 降低 内 存 占 用 从 而 在 一 定 程 度 上 避免 
OOM， 提 高 了 Bitmap 加 载 时 的 性 能 。BitmapFactory 提 供 的 加 载 图 片 的 
四 类 方法 都 支持 BitmapFactory.Options 参 数 ， 通 过 它们 就 可 以 很 方便 地 
对 一 个 图 片 进行 采样 缩放 。 








通过 BitmapFactory.Options 来 缩放 图 片 ， 主 要 是 用 到 了 它 的 
inSampleSize 参 数 ， 即 采样 率 。 当 inSampleSize 为 1 时 ， 采 样 后 的 图 片 大 
小 为 图 片 的 原始 大 小 ; 当 inSampleSize 大 于 1 时 ， 比 如 为 2， 那 么 采样 后 
的 图 片 其 宽 / 高 均 为 原 图 大 小 的 112， 而 像素 数 为 原 图 的 14， 其 占有 的 内 


存 大 小 也 为 原 图 的 /4。 拿 一 张 1024x1024 像 素 的 图 片 来 说 ， 假 定 采用 
ARGB8888 格 式 存储 ， 那 么 它 占 有 的 内 存 为 1024x1024x4， 即 4MB， 如 
果 inSampleSize 为 2， 那 么 采样 后 的 图 片 其 内 存 占用 只 有 512x512x4， 即 
1MB。 可 以 发 现 采 样 率 imSampleSize 必 须 是 大 于 1 的 整数 图 片 才 会 有 缩小 
的 效果 ， 并 且 采 样 率 同时 作用 于 宽 / 高 ， 这 将 导致 缩放 后 的 图 片 大 小 以 
采样 率 的 2 次 方形 式 递 减 ， 即 缩放 比例 为 〈inSampleSize 的 2 次 方 ) ， 
比如 inSampleSize 为 4， 那 么 缩放 比例 就 是 V16。 有 一 种 特殊 情况 ， 那 就 
是 当 inSampleSize 小 于 1 时 ， 其 作用 相当 于 1， 即 无 缩放 效果 。 男 外 最 新 
的 官方 文档 中 指出 ，inSampleSize 的 取 值 应 该 总 是 为 2 的 指数 ， 比 如 1、 
2、4、8、16， 等 等 。 如 果 外 界 传递 给 系统 的 inSampleSize 不 为 2 的 指 
数 ， 那 么 系统 会 向 下 取 整 并 选择 一 个 最 接近 的 2 的 指数 来 代替 ， 比 如 3， 
系统 会 选择 2 来 代替 ， 但 是 经 过 验证 发 现 这 个 结论 并 非 在 所 有 的 Android 
版 本 上 都 成 立 ， 因 此 把 它 当成 一 个 开发 建议 即 可 。 








考虑 以 下 实际 的 情况 ， 比 如 ImageView 的 大 小 是 100x100 像 素 ， 而 
图 片 的 原始 大 小 为 200x200， 那 么 只 le ey 
可 。 但 是 如 果 图 片 大 小 为 200x300 呢 ? 这 个 时 候 采 样 率 还 应 该 选择 2， 这 
样 缩放 后 的 图 片 大 小 为 100x150 像 素 ， 仍 然 是 适合 ImageView 的 ， 如 果 
采样 率 为 3， 那 么 缩放 后 的 图 片 大 小 就 会 小 于 ImageView 所 期 望 的 大 小 ， 
这 样 图 片 就 会 被 拉 伸 从 而 导致 模糊 。 




















通过 采样 率 即 可 有 效 地 加 载 图 片 ， 那 么 到 底 如 何 获 取 采 样 率 呢 ? 获 
取 采 样 率 也 很 简单 ， 巡 循 如 下 流程 : 





(1) 将 BitmapFactory.Options 的 inJustDecodeBounds 参 数 设 为 true 并 
加 载 图 片 。 





(2) 从 BitmapFactory.Options 中 取出 图 厂 的 原始 宽 高 信息 ， 它 们 对 


应 于 outWidth 和 outHeight 参 数 。 





(3) 根据 采样 率 的 规则 并 结合 目标 View 的 所 需 大 小 计算 出 采样 率 


inSampleSize. 


(4) 将 BitmapFactory.Options 的 inJustDecodeBounds 参 数 设 为 
false， 然 后 重新 加 载 图 片 。 


经 过 上 面 4 个 步 又， 加 载 出 的 图 片 承 是 最 终 缩放 后 的 图 片 ， 当 然 也 
有 可 能 不 需要 缩放 。 这 里 说 明 一 下 inJustDecodeBounds 参 数 ， 当 此 参数 
设 为 true 时 ，BitmapFactory 只 会 解析 网 片 的 原始 宽 / 高 信息 ， 并 不 会 去 真 
正 地 加 载 图 片 ， 所 以 这 个 操作 是 轻 量 级 的 。 男 外 需要 注意 的 是 ， 这 个 时 
候 BitmapFactory 获 取 的 图 片 宽 / 高 信息 和 图 片 的 位 置 以 及 程序 运行 的 设 
备 有 关 ， 比 如 同一 张 图 片 放 在 不 同 的 drawable 目 录 下 或 者 程序 运行 在 不 
同 屏幕 密度 的 设备 上 ， 这 都 可 能 导致 BitmapFactory 获 取 到 不 同 的 结 
之 所 以 会 出 现 这 个 现象 ， 这 和 Android 的 资源 加 载 机 制 有 关 ， 相 信 读 者 
平日 里 肯定 有 上 所 体会 ， 这 里 残 不 再 详细 说 明了 。 




















将 上 面 的 4 个 流程 用 程序 来 实现 ， 束 产生 了 下 面 的 代码 : 


public static Bitmap decodeSampledBitmapFromResource(Resource 
int reqwidth,int reqHeight) { 
// First decode with inJustDecodeBounds=true to check di 
final BitmapFactory.Options options = new BitmapFactory. 
options.inJustDecodeBounds = true; 
BitmapFactory.decodeResource(res, resid, options); 
// Calculate inSampleSize 


options.inSampleSize = calculateInSampleSize(options, req 


// Decode bitmap with inSampleSize set 
options.inJustDecodeBounds = false; 
return BitmapFactory.decodeResource(res, resid, options); 
i; 
public static int calculateInSampleSize( 
BitmapFactory.Options options,int reqwidth,int r 
// Raw height and width of image 
final int height = options.outHeight; 
final int width = options.outWidth; 
int inSampleSize = 1; 
if (height > reqHeight || width > reqwWidth) { 
final int halfHeight = height / 2; 
final int halfWidth = width / 2; 
// Calculate the largest inSampleSize value that is 
keeps both 
// height and width larger than the requested height 
while ((halfHeight / inSampleSize) => reqHeight 
&& (halfWidth / inSampleSize) => reqwidth) { 


inSampleSize *= 2; 


Í 


return inSampleSize; 


有 了 上 面 的 两 个 方法 ， 实 际 使 用 的 时 候 就 很 简单 了 ， 比 如 
ImageView 所 期 望 的 图 片 大 小 为 100x100 像 素 ， 这 个 时 候 就 可 以 通过 如 
下 方式 局 效 地 加 载 并 显示 图 片 : 


mImageView. set ImageBitmap ( 


decodeSampledBitmapFromResource(getResources(),R.id.myim 


除了 BitmapFactory 的 decodeResource 方 法 ， 其 他 三 个 decode 系 列 的 
方法 也 是 文 持 采样 加 载 的 ， 并 且 处 理 方 式 也 是 类 似 的 ， 但 是 
decodeStream 方 法 稍微 有 点 特殊 ， 这 个 会 在 后 续 内 容 中 详细 介绍 。 通 过 
本 节 的 介绍 ， 读 者 应 该 能 很 好 地 竺 握 这 种 高 效 地 加 载 图 厂 的 方法 了 。 


12.2 Android +} H 2277 Ris 


BAF ug EAndroid' tAE IZ INE BRERA mR 
场景 下 ， 组 人 存 策 略 就 变 得 更 为 重要 。 考 虑 一 种 场景 : 有 一 批 网 络 图 片 ， 
再 要 下 载 后 在 用 户 界 面 上 了 予以 显示 ， 这 个 场景 在 PC 环境 下 是 很 简单 
的 ， 直 接 把 所 有 的 图 片 下 载 到 本 地 再 显示 即 可 ， 但 是 放 到 移动 设备 上 就 
不 一 样 了 。 不 管 是 Android 还 是 iOS 设 备 ， 流 量 对 于 用 户 来 说 都 是 一 种 宝 
贯 的 资源 ， 由 于 流量 是 收费 的 ， 所 以 在 应 用 开发 中 并 不 能 过 多 地 消耗 用 
户 的 流量 ， 否 则 这 个 应 用 肯定 不 能 被 用 户 所 接受 。 再 加 上 目前 国内 公共 
场所 的 WiFi 普 及 率 并 不 算 太 高 ， 因 此 用 户 在 很 多 情况 下 手机 上 都 是 用 的 
移动 网 络 而 非 WiFi， 因 此 必须 提供 一 种 解决 方案 来 解决 流量 的 消耗 问 


elo 














如 何 避 免 过 多 的 流量 消耗 呢 ? AE AS AT VO Eel: BAF o 
当 程 序 第 一 次 从 网 络 加 载 图 片 后 ， 束 将 其 缓存 到 存储 设备 上 ， 这 样 下 次 
使 用 这 张 图 片 束 不 用 再 从 网 络 上 获取 了 ， 这 样 束 为 用 户 节 省 了 流量 。 很 
多 时 候 为 了 提高 应 用 的 用 户 体验 ， 往 往 还 会 把 图 片 在 内 存 中 再 缓存 一 
份 ， 这 样 当 应 用 打算 从 网 络 上 请 求 一 张 图 片 时 ， 程 序 会 首先 从 内 存 中 去 
获取 ， 如 果 内 存 中 没有 那 束 从 存储 设备 中 去 获取 ， 如 果 存 储 设备 中 也 没 
有 ， 那 就 从 网 络 上 下 载 这 张 图 片 。 因 为 从 内 存 中 加 载 图 片 比 从 存储 设备 
中 加 载 图 片 要 快 ， 所 以 这 样 既 扣 高 了 程序 的 效率 又 为 用 尸 节 约 了 不 必要 
的 流量 开销 。 上 述 的 缓存 策略 不 仅仅 适用 于 图 片 ， 也 适用 于 其 他 文件 类 
型 5 








说 到 缓存 策略 ， 其 实 并 没有 统一 的 标准 。 一 般 来 说 ， 绥 人 存 策略 主要 
包含 缓存 的 添加 、 获 取 和 删除 这 三 类 操作 。 如 何 谎 加 和 获取 缓存 这 个 比 














较 好 理解 ， 那 么 为 什么 还 要 删除 缓存 呢 ? 这 是 因为 不 管 是 内 存 缓存 还 是 
存储 设备 缓存 ， 它 们 的 缓存 大 小 都 是 有 限制 的 ， 因 为 内 存 和 诸如 SD 卡 

之 类 的 存储 设备 都 是 有 容量 限制 的 ， 因 此 在 使 用 缓存 时 总 是 要 为 缓存 指 
定 一 个 最 大 的 容量 。 如 果 当 缓存 容量 满 了 了 ， 但 是 程序 还 需要 问 其 添加 组 
存 ， 这 个 时 候 该 怎么 办 呢 ? 这 如 需要 删除 一 些 旧 的 缓存 并 添加 新 的 组 

存 ， 如 何 定 义 缓存 的 新 旧 这 就 是 一 种 策略 ， 不 同 的 策略 束 对 应 着 不 同 的 
绥 存 算法 ， 比 如 可 以 简单 地 根据 文件 的 最 后 修改 时 间 来 定义 缓存 的 新 

旧 ， 当 绥 存 满 时 就 将 最 后 修改 时 间 较 早 的 缓存 移 除 ， 这 就 是 一 种 缓存 算 
法 ， 但 是 这 种 算法 并 不 算 很 完美 。 


























目前 常用 的 一 种 缓存 算法 是 LRU (Least Recently Used) , LRUÆ 
近期 最 少 使 用 算法 ， 它 的 核心 思想 是 当 绥 存 满 时 ， 会 优先 淘汰 那些 近期 
最 少 使 用 的 缓存 对 象 。 采 用 LRU 算 法 的 缓存 有 两 种 : LruCache 和 
DiskLruCache，LruCache 用 于 实现 内 存 缓存 ， 而 DiskLruCache 则 充当 了 
存储 设备 缓存 ， 通 过 这 二 者 的 完美 结合 ， 就 可 以 很 方便 地 实现 一 个 具有 
很 高 实用 价值 的 ImageLoader。 本 市 首先 会 介绍 LruCache 和 
DiskLruCache， 然 后 利用 LruCache 和 DiskLruCache 来 实现 一 个 优秀 的 
ImageLoader， 并 且 提 供 一 个 使 用 ImageLoader 来 从 网 络 下 载 并 展示 图 片 
的 例子 ， 在 这 个 例子 中 体现 了 ImageLoader 以 及 大 批量 网 络 图片 加 载 所 
涉及 的 大 量 技术 点 。 





12.2.1 LruCache 


LruCache 是 Android 3.1 所 提供 的 一 个 缓存 类 ， 通 过 support-v4 兼 容 包 
可 以 兼容 到 早期 的 Android 版 本 ， 目 前 Android 2.2 以 下 的 用 户 量 已 经 很 少 
了 ， 因 此 我 们 开发 的 应 用 兼容 到 Android 2.2 就 已 经 足够 了 。 为 了 能 够 兼 


4 Android 2.2 版 本 ， 在 使 用 LruCache 时 建议 采用 supportrv4 兼 容 包 中 提供 
的 LruCache， 而 不 要 直接 使 用 Android 3.1 提 供 的 LruCache。 


LruCache 是 一 个 泛 型 类 ， 它 内 部 采用 一 个 LinkedHashMap 以 强 引 用 
的 方式 存储 外 界 的 缓存 对 象 ， 其 提供 了 get 和 put 方法 来 完成 缓存 的 获取 
和 添加 操作 ， 当 缓存 满 时 ，LruCache 会 移 除 较 早 使 用 的 缓存 对 象 ， 然 后 
再 添加 新 的 缓存 对 象 。 这 里 读者 要 明白 强 引 用 、 软 引用 和 弱 引 用 的 区 
别 ， 如 下 所 示 。 





。 强 引用 : 直接 的 对 象 引 用 ; 

。 软 引用 : 当 一 个 对 象 只 有 软 引 用 存在 时 ， 系 统 内 存 不 足 时 此 对 象 会 
被 gc 回收 ; 

。 弱 引用 : 当 一 个 对 象 只 有 弱 引 用 存在 时 ， 此 对 象 会 随时 被 gc 回收 。 





男 外 LruCache 是 线程 安全 的 ， 下 面 是 LruCache 的 定义 : 


public class LruCache<K,V> { 


private final LinkedHashMap<K, V> map; 


} 


LruCache 的 实现 比较 简单 ， 读 者 可 以 参考 它 的 源码 ， 这 里 仅 介 绍 如 
何 使 用 LruCache 来 实现 内 存 缓存 。 仍 然 拿 图 片 缓存 来 举例 子 ， 下 面 的 代 
码 展 示 了 LruCache 的 典型 的 初始 化 过 程 : 











int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 102 
int cacheSize = maxMemory / 8; 
mMemoryCache = new LruCache<String, Bitmap>(cacheSize) { 


@Override 


protected int sizeOf(String key,Bitmap bitmap) { 
return bitmap.getRowBytes() * bitmap.getHeight() 


ti 








在 上 面 的 代码 中 ， 只 需要 提供 缓存 的 总 容量 大 小 并 重 写 sizeOf 方 法 
即 可 。sizeOf 方 法 的 作用 是 计算 缓存 对 象 的 大 小 ， 这 里 大 小 的 单位 需要 
和 总 容量 的 单位 一 致 。 对 于 上 面 的 示例 代码 来 说， 总 容量 的 大 小 为 当前 
进程 的 可 用 内 存 的 18， 单 位 为 KB， 而 sizeOf 方 法 则 完成 了 Bitmap 对 象 
的 大 小 计算 。 很 明显 ， 之 所 以 除 以 1024 也 是 为 了 将 其 单位 转换 为 KB。 
一 些 特殊 情况 下 ， 还 需要 重 写 LruCache 的 entryRemoved 方 法 ，LruCache 
移 除 旧 缓存 时 会 调用 entryRemoved 方 法 ， 因 此 可 以 在 entryRemoved 中 完 
成 一 些 资源 回收 工作 《如 果 需 要 的 话 ) 。 

















除了 LruCache 的 创建 以 外 ， 还 有 绥 存 的 获取 和 添加 ， 这 也 很 简单 ， 
从 LruCache 中 获取 一 个 缓存 对 象 ， 如 下 所 示 。 


mMemoryCache.get(key) 


问 LruCache 中 添加 一 个 缓存 对 象 ， 如 下 所 示 。 


mMemoryCache.put(key,bitmap) 


LruCache 还 支持 删除 操作 ， 通 过 remove 方 法 即 可 删除 一 个 指定 的 缓 
存 对 象 。 可 以 看 到 LruCache 的 实现 以 及 使 用 都 非常 简单 ， 虽 然 简单 ， 但 
是 仍然 不 影响 它 具 有 强大 的 功能 ， 从 Android 3.1 开 始 ，LruCache 束 已 经 
是 Android 源 码 的 一 部 分 了 。 





12.2.2 DiskLruCache 





DiskLruCache 用 于 实现 存储 设备 缓存 ， 即 磁盘 缓存 ， 它 通过 将 缓存 
对 象 写 入 文件 系统 从 而 实现 缓存 的 效果 。DiskLruCache 得 到 了 Android 官 
方 文档 的 推荐 ， 但 它 不 属于 Android SDK 的 一 部 分 ， 它 的 源码 可 以 从 如 
下 网 址 得 到 ; 


https://android.googlesource.com/platform/libcore/+/android-4 





需要 注意 的 是 ， 从 上 述 网 址 获取 的 DiskLruCache 的 源码 并 不 能 直接 
在 Android 中 使 用 ， 需 要 稍微 修改 编译 错误 。 下 面 分 别 从 DiskLruCache 的 
创建 、 绥 存 查找 和 缓存 添 加 这 三 个 方面 来 介绍 DiskLruCache 的 使 用 方 
Ae 





1. DiskLruCache 的 创建 





DiskLruCache 并 不 能 通过 构造 方法 来 创建 ， 它 提供 了 open 方 法 用 于 
Ge A, oR Arma. 


public static DiskLruCache open(File directory,int appVersion 





open N ZA URS, FPO — PSS BCR AN RRT TE EAA 
的 存储 路 径 。 绥 存 路 径 可 以 选择 SD 卡 上 的 绥 存 目录 ， 有 具体 是 
指 /sdcard/Android/data/package_name/cache 目 录 ， 其 中 package_name 表 示 
当前 应 用 的 包 名 ， 当 应 用 被 秋 载 后 ， 此 目录 会 一 并 被 删除 。 当 然 也 可 以 
选择 SD 卡 上 的 其 他 指定 目录 ， 还 可 以 选择 data 下 的 当前 应 用 的 目录 ， 具 
体 可 根据 需要 灵活 设 定 。 这 里 给 出 一 个 建议 :如 果 应 用 弛 载 后 就 希望 删 
除 绥 存 文件， 那么 就 选择 SD 卡 上 的 缓存 目录 ， 如 果 希 望 保留 绥 存 数据 














那 就 应 该 选择 SD 卡 上 的 其 他 特定 目录 。 


第 二 个 参数 表示 应 用 的 版 本 号 ， 一 般 设 为 1 即 可 。 当 版 本 号 及 生 改 
变 时 DiskLruCache 会 清空 之 前 所 有 的 缓存 文件 ， 而 这 个 特性 在 实际 开发 
中 作用 并 不 大 ， 很 多 情况 下 即使 应 用 的 版 本 号 发 生 了 改变 缓存 文件 却 仍 
然 是 有 效 的 ， 因 此 这 个 参数 设 为 1 比较 好 。 


三 个 参数 表示 单个 节点 所 对 应 的 数据 的 个 数 ， 一 般 设 为 1 即 可 。 
P a 比如 50MB， 当 缓存 大 小 超出 这 个 设 定 
值 后 ，DiskLruCache 会 清除 一 些 绥 存 从 而 保证 总 大 小 不 大 于 这 个 设 定 
值 。 下 面 是 一 个 典型 的 DiskLruCache 的 创建 过 程 : 








private static final long DISK_CACHE_SIZE = 1024 * 1024 * 50; 
File diskCacheDir = getDiskCacheDir(mContext, "bitmap"); 
if (!diskCacheDir.exists()) { 

diskCacheDir .mkdirs(); 


} 
mDiskLruCache = DiskLruCache.open(diskCacheDir,1,1,DISK CACHE 


2. DiskLruCache 的 绥 存 添加 


DiskLruCache 的 缓存 添加 的 操作 是 通过 Editor 完 成 的 ，Editor 表 示 一 
REAM RIN SFT A KAU AREAS, Hm BRA A A 
arly) 对 应 的 key， 然 后 根据 key 就 可 以 通过 edit() 来 获取 Editor 对 象 ， 如 果 

这 个 绥 存 正在 被 编辑 ， 那 么 edit0 会 返回 null， 即 DiskLruCache 不 允许 同 
时 编辑 一 个 缓存 对 象 。 之 所 以 要 把 rl 转换 成 key， 是 因为 图 片 的 url 中 很 
可 能 有 特殊 字符 ， 这 将 影响 url 在 Android 中 直接 使 用 ， 一 般 采 用 unl 的 
md5 值 作为 key， 如 下 所 示 。 




















将 图 片 的 url 转 成 key 以 后 ， 就 可 以 获取 Editor 对 象 了 。 对 于 这 个 key 
来 说 ， 如 果 当 前 不 存在 其 他 Editor 对 象 ， 那 么 editO 就 会 返回 一 个 新 的 
Editor 对 象 ， 通 过 它 就 可 以 得 到 一 个 文件 输出 流 。 需 要 注意 的 是 ， 由 于 
前 面 在 DiskLruCache 的 open 方 法 中 设置 了 一 个 节点 只 能 有 一 个 数据 ， 





此 下 面 的 DISK_CACHE_INDEX 常 量 直接 设 为 0 即 可 ， 如 下 所 示 。 


String key = hashKeyFormUrl(url); 
DiskLruCache.Editor editor = mDiskLruCache.edit(key); 
if (editor != null) { 
OutputStream outputStream = editor.newOutputStream(DISK_C 


有 了 文件 输出 流 ， 接 下 来 要 怎么 做 呢 ?” 其 实 是 这 样 的 ， 当 从 网 络 下 
载 图 片 时 ， 图 片 就 可 以 通过 这 个 文件 输出 流 写 入 到 文件 系统 上 ， 这 个 过 
程 的 实现 如 下 所 示 。 


public boolean downloadUrlToStream(String urlString, 

OutputStream outputStream) { 

HttpURLConnection urlConnection = null; 

BufferedOutputStream out = null; 

BufferedInputStream in = null; 

try { 
final URL url = new URL(urlString); 
urlConnection = (HttpURLConnection) url.openConne 
in = new BufferedInputStream(urlConnection.getiInp 

IO0_BUFFER_SIZE); 


out = new BufferedOutputStream(outputStream, IO_BU 


int b; 

while ((b = in.read()) != -1) { 
out.write(b); 

Í 


return true; 





经 过 上 面 的 步 又， 其 实 并 没有 真正 地 将 图 片 写 入 文件 系统 ， 还 必须 
过 Editor 的 commit() 来 提交 写 入 操作 ， 如 果 图 片 下 载 过 程 发 生 了 异 
， 那 么 还 可 以 通过 Editor 的 abort0 来 回 退 整个 操作 ， 这 个 过 程 如 下 所 
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经 过 上 面 的 几 个 步骤 ， 图 片 已 经 被 正确 地 写 入 到 文件 系统 了 ， 接 下 
来 图 片 获取 的 操作 就 不 需要 请 求 网 络 了 。 


3. DiskLruCache 的 绥 存 查找 





和 缓存 的 添加 过 程 类 似 ， 绥 存 碍 找 过 程 也 需要 将 由 转换 为 key， 然 
后 通过 DiskLruCache 的 get 方 法 得 到 一 个 Snapshot 对 象 ， 接 着 再 通过 
Snapshot 对 象 即 可 得 到 缓存 的 文件 输入 沪 ， 有 了 文件 输出 流 ， 上 自然 就 可 
以 得 到 Bitmap 对 象 了 了。 为 了 避免 加 载 图片 过 程 中 导致 的 OOM 问 题 ， 一 
般 不 建议 直接 加 载 原始 图 片 。 在 第 12.1 节 中 已 经 介绍 了 通过 
BitmapFactory.Options 对 象 来 加 载 一 张 缩放 后 的 图 片 ， 但 是 那 种 方法 对 
FileInputStream 的 缩放 存在 问题 ， 原 因 是 FileInputStream 是 一 种 有 序 的 文 
件 流 ， 而 两 次 decodeStream 调 用 影响 了 文件 流 的 位 置 属性 ， 导 致 了 第 二 
次 decodeStream 时 得 到 的 是 nul。 为 了 解决 这 个 问题 ， 可 以 通过 文件 沈 
来 得 到 它 所 对 应 的 文件 描述 符 ， 然 后 再 通过 
BitmapFactory.decodeFileDescriptor 方 法 来 加 载 一 张 缩放 后 的 图 片 ， 这 个 
过 程 的 实现 如 下 所 示 。 





Bitmap bitmap = null; 
String key = hashKeyFormUrl(url); 
DiskLruCache.Snapshot snapShot = mDiskLruCache.get(key); 
if (snapShot != null) { 
FileInputStream fileInputStream = (FileInputStream)snapSh 
FileDescriptor fileDescriptor = fileInputStream.getFD(); 
bitmap = mImageResizer .decodeSampledBitmapFromFileDescrip 
reqwidth, reqHeight); 
if (bitmap != null) { 
addBitmapToMemoryCache(key, bitmap) ; 


上 上 面 介 绍 了 DiskLruCache 的 创建 、 绥 存 的 添加 和 得 找 过 程 ， 读 者 应 
该 对 DiskLruCache 的 使 用 方式 有 了 一 个 大 致 的 了 解 ， 除 此 之 外 ， 
DiskLruCache 还 提供 了 remove、delete 等 方法 用 于 磁盘 缓存 的 删除 操 
作 。 关 于 DiskLruCache 的 内 部 实现 这 里 就 不 再 介绍 了 ， 读 者 感 兴 趣 的 话 
可 以 查看 它 的 源码 实现 。 





12.2.3 ”ImageLoader 的 实现 


在 本 章 的 前 面 先 后 介绍 了 Bitmap 的 高 效 加 载 方 式 、LruCache 以 及 
DiskLruCache， 现 在 我 们 来 着 手 实现 一 个 优秀 的 InageLoader。 





- 般 来 说 ， 一 个 优秀 的 ImageLoader 应 该 具备 如 下 功能 


图 片 的 同步 加 载 ; 
图 片 的 异步 加 载 ; 
图 片 压缩 ; 
内 存 缓存 ; 
磁盘 缓存 ; 
网 络 拉 取 。 


图 片 的 同步 加 载 是 指 能 够 以 同步 的 方式 回调 用 者 提供 所 加 载 的 图 
BEM A Fee PR, thay A o 
的 ， 还 可 能 是 从 网 络 拉 取 的 。 图 乒 的 异步 加 载 是 一 个 很 有 用 的 功能 
oe ee 
ImageLoader 内 部 需要 上 自己 在 线程 中 加 载 图 乒 并 将 图 片 设置 给 所 需 的 
ImageView。 图 片 压 缩 的 作用 更 给 良 置 疑 了 ， 这 是 降低 OOM 概 率 的 有 效 
手段 ，ImageLoader 必 须 合适 地 处 理 图 片 的 压缩 问题 。 














内 存 缓存 和 破 盘 缓存 是 ImageLoader 的 核心 ， 也 是 ImageLoader 的 意 
义 之 所 在 ， 通 过 这 两 级 缓存 极 大 地 提高 了 程序 的 效率 并 且 有 效 地 降低 了 
对 用 户 所 造成 的 流量 消耗 ， 只 有 当 这 两 级 绥 存 都 不 可 用 时 才 需 要 从 网 络 
中 拉 取 图 片 。 


除 此 之 外 ，ImageLoader 还 需要 处 理 一 些 特殊 的 情况 ， 比 如 在 
ListView 或 者 GridView 中 ，View 复 用 既是 它们 的 优点 也 是 它们 的 缺点 ， 
优点 想必 读者 都 很 清楚 了 ， 那 缺点 可 能 还 不 太 清 楚 。 考 虑 一 种 情况 ， 在 
ListView 或 者 GridView 中 ， 假 设 一 个 item ”A 正在 从 网 络 加 载 图 片 ， 它 对 
应 的 ImageView 为 A， 这 个 时 候 用 户 快 速 同 下 滑动 列表 ， 很 可 能 item BE 
用 了 ImageView A， 然 后 等 了 一 会 之 前 的 图 片 下 载 完 毕 了 。 如 果 直 接 给 
ImageView A 设置 图 片 ， 由 于 这 个 时 候 ImageView A 被 item B 所 复 用 ， 但 
item B 要 显示 的 图 片 显 然 不 是 item A 刚刚 下 载 好 的 图 片 ， 这 个 时 候 就 
会 出 现 item B 中 显示 了 item A 的 图 片 ， 这 就 是 常见 的 列表 的 错位 问题 ， 
ImageLoader 需 要 正确 地 处 理 这 些 特殊 情况 。 








上 面 对 ImageLoader 的 功能 做 了 一 个 全 面 的 分 析 ， 下 面 就 可 以 一 步 
步 实 现 一 个 ImageLoader 了 ， 这 里 主要 分 为 如 下 几 步 。 


1. 图片 压缩 功能 的 实现 


图 斤 压 缩 在 第 12.1 节 中 已 经 做 了 介绍 ， 这 里 束 不 再 多 说 了 ， 为 了 有 
民 好 的 设计 风格 ， 这 里 单独 抽象 了 一 个 类 用 于 完成 图 瞩 的 压缩 功能 ， 这 
个 类 叫 ImageResizer， 它 的 实现 如 下 所 示 。 


public class ImageResizer { 
private static final String TAG = "ImageResizer"; 


public ImageResizer() { 


} 


public Bitmap decodeSampledBitmapFromResource(Resources 


} 


int resId,int reqwidth,int reqHeight) { 
// First decode with inJustDecodeBounds=true to chec 
final BitmapFactory.Options options = new BitmapFact 
options.inJustDecodeBounds = true; 
BitmapFactory.decodeResource(res, resid, options); 
// Calculate inSampleSize 
options.inSampleSize = calculateInSampleSize(options 
// Decode bitmap with inSampleSize set 
options.inJustDecodeBounds = false; 


return BitmapFactory.decodeResource(res, resid, option 


public Bitmap decodeSampledBitmapFromFileDescriptor (File 


int reqwidth,int reqHeight) { 


上 


// First decode with inJustDecodeBounds=true to chec 
final BitmapFactory.Options options = new BitmapFact 
options.inJustDecodeBounds = true; 
BitmapFactory.decodeFileDescriptor(fd,null, options); 
// Calculate inSampleSize 

options.inSampleSize = calculateInSampleSize(options 
// Decode bitmap with inSampleSize set 
options.inJustDecodeBounds = false; 


return BitmapFactory.decodeFileDescriptor(fd,null, op 


public int calculateInSampleSize(BitmapFactory.Options o 


int reqwidth,int reqHeight) { 


2. 内 存 缓存 和 磁盘 缓存 的 实现 





这 里 选择 LruCache 和 DiskLruCache 来 分 别 完 成 内 存 缓存 和 磁盘 绥 存 
的 工作 。 在 ImageLoader 初 始 化 时 ， 会 创建 LruCache 和 DiskLruCache， 如 
下 所 示 。 


private LruCache<String, Bitmap> mMemoryCache; 
private DiskLruCache mDiskLruCache; 
private ImageLoader(Context context) { 
mContext = context.getApplicationContext(); 
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 
int cacheSize = maxMemory / 8; 
mMemoryCache = new LruCache<String, Bitmap>(cacheSize) { 
@Override 
protected int sizeOf(String key,Bitmap bitmap) { 


return bitmap.getRowBytes() * bitmap.getH 


}; 
File diskCacheDir = getDiskCacheDir(mContext,"bitmap"); 
if (!diskCacheDir.exists()) { 
diskCacheDir.mkdirs(); 
} 
if (getUsableSpace(diskCacheDir) > DISK_CACHE_SIZE) { 
try { 
mDiskLruCache = DiskLruCache.open(diskCac 
DISK_CACHE_SIZE); 
mIsDiskLruCacheCreated = true; 
} catch (IOException e) { 


e.printStackTrace(); 


} 





在 创建 磁盘 缓存 时 ， 这 里 做 了 一 个 判断 ， 即 有 可 能 磁盘 剩余 空间 小 
于 人 磁盘 缓存 所 需 的 大 小 ， 一 般 是 指 用 户 的 手机 空间 已 经 不 足 了 ， 因 此 没 
有 办 法 创建 磁盘 缓存 ， 这 个 时 候 磁盘 缓存 就 会 失效 。 在 上 面 的 代码 实现 
中 ，ImageLoader 的 内 存 缓存 的 容量 为 当前 进程 可 用 内 存 的 18， 磁盘 绥 
存 的 容量 为 50MB。 




















内 存 缓存 和 磁盘 缓存 创建 完毕 后 ， 还 需要 提供 方法 来 完成 缓存 的 添 
加 和 获取 功能 。 首 先 看 内 存 缓存， 它 的 添加 和 读 取 过 程 比较 简单 ， 如 下 
所 示 。 





private void addBitmapToMemoryCache(String key,Bitmap bitmap) 
if (getBitmapFromMemCache(key) == null) { 


mMemoryCache.put(key, bitmap); 


} 
private Bitmap getBitmapFromMemCache(String key) { 


return mMemoryCache.get(key); 


} 
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12.2.2 节 中 进行 了 详细 的 介绍 ， 这 里 再 简单 说 明 一 下 。 磁 盘 绥 存 的 添加 
需要 通过 Editor 来 完成 ，Editor 提 供 了 commit 和 abort 方 法 来 提交 和 撤销 对 
文件 系统 的 写 操作 ， 具 体 实现 请 参看 下 面 的 loadBitmap-FromHttp 方 法 。 
人 厂 盘 绥 存 的 读 取 需 要 通过 Snapshot 来 完成 ， 通 过 Snapshot 可 以 得 到 厂 盘 





缓存 对 象 对 应 的 FileInputStream， 但 是 FileInputStream 无 法 便捷 地 进行 压 
绽 ， 所 以 通过 FileDescriptor 来 加 载 压缩 后 的 图 片 ， 最 后 将 加 载 后 的 
Bitmap 深 加 到 内 存 缓存 中 ， 有 具体 实现 请 参看 下 面 的 
loadBitmapFromDiskCache 方 法 。 








private Bitmap loadBitmapFromHttp(String url,int reqwidth, int 
throws IOException { 
if (Looper.myLooper() == Looper.getMainLooper()) { 
throw new RuntimeException("can not visit network 
j 
if (mDiskLruCache == null) { 
return null; 
j 
String key = hashKeyFormUrl(url); 
DiskLruCache.Editor editor = mDiskLruCache.edit(key); 
if (editor != null) { 
OutputStream outputStream = editor.newOutputStrea 
if (downloadUrlToStream(url,outputStream)) { 
editor.commit(); 
} else { 
editor.abort(); 


} 
mDiskLruCache.flush(); 


t 
return loadBitmapFromDiskCache(url, reqwidth, reqHeight ) ; 


t 


private Bitmap loadBitmapFromDiskCache(String url,int reqwidt 


3. 同步 加 载 和 异步 加 载 接口 的 设计 


首先 看 同步 加 载 ， 同 步 加 载 接口 需要 外 部 在 线程 中 调用 ， 这 是 因为 
同步 加 载 很 可 能 比较 耗 时 ， 它 的 实现 如 下 所 示 。 





* load bitmap from memory cache or disk cache or network. 
* @param uri http url 
* @param reqwidth the width ImageView desired 
* @param reqHeight the height ImageView desired 
* @return bitmap,maybe null. 
ee 
public Bitmap loadBitmap(String uri,int reqWidth, int reqHeigh 
Bitmap bitmap = loadBitmapFromMemCache(ur1i)j; 
if (bitmap != null) { 
Log.d(TAG, "loadBitmapFromMemCache,url:" + uri); 


return bitmap; 


try { 


bitmap = loadBitmapFromDiskCache(uri, reqwidth, req 
if (bitmap != null) { 
Log.d(TAG, "loadBitmapFromDisk,url:" + uri 
return bitmap; 
} 
bitmap = loadBitmapFromHttp(uri, reqwidth, reqHeigh 
Log.d(TAG, "loadBitmapFromHttp,url:" + uri); 
} catch (IOException e) { 
e.printStackTrace(); 
Í 
if (bitmap == null && !mIsDiskLruCacheCreated) { 
Log.w(TAG, "encounter error,DiskLruCache is not cr 


bitmap = downloadBitmapFromUrl(uri); 


return bitmap; 


从 loadBitmap 的 实现 可 以 看 出 ， 其 工作 过 程 遵循 如 下 几 步 : 首先 答 
试 从 内 存 缓存 中 读 取 图 片 ， 接 着 答 试 从 磁盘 缓存 中 读 取 网 乒 ， 最 后 才 从 
网 络 中 拉 取 图 片 。 另 外 ， 这 个 方法 不 能 在 主线 程 中 调用 ， 人 否则 残 执 出 腊 
常 。 这 个 执行 环境 的 检查 是 在 loadBitmapFromHttp 中 实现 的 ， 通 过 检查 
当前 线程 的 Looper 是 否 为 主线 程 的 Looper 来 判断 当前 线程 是 否 是 主线 
程 ， 如 果 不 是 主线 程 就 直接 抛 出 民利 中 止 程序 ， 如 下 所 示 。 








if (Looper.myLooper() == Looper.getMainLooper()) { 


throw new RuntimeException("can not visit network from UI 


接着 看 异步 加 载 接口 的 设计 ， 如 下 所 示 。 


public void bindBitmap(final String uri,final ImageView image 

final int reqwidth, final int reqHeight) { 

imageView.setTag(TAG_KEY_URI,uri); 

Bitmap bitmap = loadBitmapFromMemCache(ur1)j; 

if (bitmap != null) { 
imageView.setImageBitmap(bitmap) ; 
return; 

} 

Runnable loadBitmapTask = new Runnable() { 
@Override 
public void run() { 


Bitmap bitmap = loadBitmap(uri, reqwidth,r 


if (bitmap != null) { 
LoaderResult result = new LoaderR 


mMainHandler .obtainMessage(MESSAG 


}; 
THREAD_POOL_EXECUTOR.execute(loadBitmapTask); 


从 bindBitmap 的 实现 来 看 ，bindBitmap 方 法 会 尝试 从 内 存 绥 存 中 读 
取 图 乒 ， 如 果 读 取 成 功 就 直接 返回 结果 ， 人 否则 会 在 线程 池 中 去 调用 
loadBitmap 方 法 ， 当 图 片 加 载 成 功 后 再 将 图 片 、 图 卢 的 地 址 以 及 需要 绑 
定 的 imageView 封 装 成 一 个 LoaderResult 对 象 ， 然 后 再 通过 mMainHandler 
器 主线 程 发 送 一 个 消息 ， 这 样 就 可 以 在 主线 程 中 给 imageView 设 置 图 片 
了 ， 之 所 以 通过 Handler 来 中 转 是 因为 子 线程 无 法 访问 UI。 














bindBitmap 中 用 到 了 线程 池 和 Handler， 这 里 看 一 下 它们 的 实现 ， 首 
先 看 线程 池 THREAD_POOL_EXECUTOR 的 实现 ， 如 下 所 示 。 可 以 看 出 
它 的 核心 线程 数 为 当前 设备 的 CPU 核心 数 加 1， 最 大 容量 为 CPU 核心 数 
的 2 倍加 1， 线 程 用 置 超时 时 长 为 10 秒 ， 关 于 线程 池 的 详细 介绍 可 以 参看 
第 11 章 的 有 关内 容 。 


private static final int CORE_POOL_SIZE = CPU_COUNT + 1; 

private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 + 

private static final long KEEP_ALIVE = 10L; 

private static final ThreadFactory sThreadFactory = new Threa 
private final AtomicInteger mCount = new AtomicInteger(1) 


public Thread newThread(Runnable r) { 


return new Thread(r,"ImageLoader#" + mCount.getAn 


3; 

public static final Executor THREAD_POOL_EXECUTOR = new Threa 
CORE_POOL_SIZE,MAXIMUM_POOL_SIZE, 
KEEP_ALIVE, TimeUnit.SECONDS, 


new LinkedBlockingQueue<Runnable>(),sThreadFactor 








之 所 以 采用 线程 池 是 有 原因 的 ， 首 先 肯 定 不 能 采用 普通 的 线程 去 做 
这 个 事 ， 线 程 池 的 好 处 在 第 11 章 已 经 做 了 详细 的 说 明 。 如 果 直 接 采 用 普 
通 的 线程 去 加 载 图 片 ， 随 着 列表 的 滑动 这 可 能 会 产生 大 量 的 线程 ， 这 样 
并 不 利于 整体 效率 的 提升 。 另 外 一 点 ， 这 里 也 没有 选择 采用 
AsyncTask，AsyncTask 封 装 了 线程 池 和 Handler， 按 道理 它 应 该 适合 
ImageLoader 的 场景 。 从 第 11 章 中 对 AsyncTask 的 分 析 可 以 知道 ， 
AsyncTask 在 3.0 的 低 版 本 和 高 版 本 上 具有 不 同 的 表现 ， 在 3.0 以 上 的 版 本 
AsyncTask 无 法 实现 并 发 的 效果 ， 这 显然 是 不 能 接受 的 ， 因 为 
ImageLoader 就 是 需要 并 发 特性 ， 昌 然 可 以 通过 改造 AsyncTask 或 者 使 用 
AsyncTask 的 executeOnExecutor 方 法 的 形式 来 执行 异步 任务 ， 但 是 这 终 
归 是 不 太 自 然 的 实现 方式 。 鉴 于 以 上 两 点 原因 ， 这 里 选择 线程 池 和 
Handler 来 提供 ImageLoader 的 并 发 能 力 和 访问 UI 的 能 力 。 





分 析 完 线程 池 的 选择 ， 下 面 看 一 下 Handler 的 实现 ， 如 下 所 示 。 
ImageLoader 直 接 采 用 主线 程 的 Looper 来 构造 Handler 对 象 ， 这 就 使 得 
ImageLoader 可 以 在 非 主线 程 中 构造 了 。 另 外 为 了 解决 由 于 View 复 用 所 
导致 的 列表 错位 这 一 问题 ， 在 给 ImageView 设 置 图 片 之 前 都 会 检查 它 的 
Url 有 没有 发 生 改 变 ， 如 果 发 生 改变 就 不 再 给 它 设 置 图 片 ， 这 样 束 解决 了 
列表 错位 的 问题 。 





private Handler mMainHandler = new Handler (Looper .getMainLoop 

@Override 

public void handleMessage(Message msg) { 
LoaderResult result = (LoaderResult) msg.obj; 
ImageView imageView = result.imageView; 
imageView.setImageBitmap(result.bitmap) ; 
String uri = (String) imageView.getTag(TAG_KEY_UR 
if (uri.equals(result.uri)) { 

imageView.setImageBitmap(result.bitmap) ; 

} else { 


Log.w(TAG, "set image bitmap,but url has c 


}; 
F 





到 此 为 止 ，ImageLoader 的 细节 都 已 经 做 了 全 面 的 分 析 ， 下 面 是 
ImageLoader 的 完整 的 代码 。 


public class ImageLoader { 
private static final String TAG = "ImageLoader"; 
public static final int MESSAGE_POST_RESULT = 1; 
private static final int CPU_COUNT = Runtime. getRuntime( 
private static final int CORE_POOL_SIZE = CPU_COUNT + 1; 
private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 
private static final long KEEP_ALIVE = 10L; 
private static final int TAG_KEY_URI = R.id.imageloader_ 
private static final long DISK_CACHE_SIZE = 1024 * 1024 


private static final int IO_BUFFER_SIZE = 8 * 1024; 

private static final int DISK_CACHE_INDEX = 0; 

private boolean mIsDiskLruCacheCreated = false; 

private static final ThreadFactory sThreadFactory = new 
private final AtomicInteger mCount = new AtomicInteg 
public Thread newThread(Runnable r) { 


return new Thread(r,"ImageLoader#" + mCount.getA 


}; 
public static final Executor THREAD_POOL_EXECUTOR = new 
Executor ( 
CORE_POOL_SIZE,MAXIMUM_POOL_SIZE, 
KEEP_ALIVE, TimeUnit.SECONDS, 
new LinkedBlockingQueue<Runnable>(),sThreadFacto 
private Handler mMainHandler = new Handler(Looper.getMai 
@Override 
public void handleMessage(Message msg) { 
LoaderResult result = (LoaderResult) msg.obj; 
ImageView imageView = result.imageView; 
imageView.setImageBitmap(result.bitmap) ; 
String uri = (String) imageView.getTag(TAG_KEY_U 
if (uri.equals(result.uri)) { 
imageView.setImageBitmap(result.bitmap) ; 
} else { 


Log.w(TAG, "set image bitmap, but url has chan 


ti 


ti 

private 
private 
private 
private 


private 


Context mContext; 

ImageResizer mImageResizer = new ImageResizer()j; 
LruCache<String, Bitmap> mMemoryCache; 
DiskLruCache mDiskLruCache; 


ImageLoader(Context context) { 


mContext = context.getApplicationContext(); 


int 


int 


maxMemory = (int) (Runtime.getRuntime().maxMemor 


cacheSize = maxMemory / 8; 


mMemoryCache = new LruCache<String, Bitmap>(cacheSize 


J 


@Override 
protected int sizeOf(String key,Bitmap bitmap) { 


return bitmap.getRowBytes() * bitmap.getHeig 


File diskCacheDir = getDiskCacheDir(mContext, "bitmap 


if (!diskCacheDir.exists()) { 


t 


diskCacheDir.mkdirs(); 


if (getUsableSpace(diskCacheDir) > DISK_CACHE_SIZE) 


try { 
mDiskLruCache = DiskLruCache.open(diskCacheD 
DISK_CACHE_SIZE); 
mIsDiskLruCacheCreated = true; 
} catch (IOException e) { 


e.printStackTrace(); 














private Bitmap loadBitmapFromDiskCache(String url,int re 


int reqHeight) throws IOException { 
if (Looper.myLooper() == Looper.getMainLooper()) { 
Log.w(TAG,"load bitmap from UI Thread,it's not r 
} 
if (mDiskLruCache == null) { 
return null; 
} 
Bitmap bitmap = null; 
String key = hashKeyFormUrl(url); 
DiskLruCache.Snapshot snapShot = mDiskLruCache.get(k 
if (snapShot != null) { 
FileInputStream fileInputStream = (FileInputStre 
get InputStream(DISK_CACHE_INDEX) ; 
FileDescriptor fileDescriptor = fileInputStream. 
bitmap = mImageResizer .decodeSampledBitmapFromFi 
(fileDescriptor, reqwidth, reqHeight ); 
if (bitmap != null) { 


addBitmapToMemoryCache(key, bitmap); 


J 


return bitmap; 


public boolean downloadUrlToStream(String urlString, 


OutputStream outputStream) { 


HttpURLConnection urlConnection = null; 








} 
private String bytesToHexString(byte[] bytes) { 
StringBuilder sb = new StringBuilder(); 
for (int i = 0; i < bytes.length; i++) { 
String hex = Integer.toHexString(OxFF & bytes[1i] 
if (hex.length() == 1) { 
sb.append('0'); 
} 
sb.append(hex); 
} 
return sb.toString(); 
} 
public File getDiskCacheDir(Context context,String uniqu 
boolean externalStorageAvailable = Environment 
.getExternalStorageState().equals(Environmen 
final String cachePath; 
if (externalStorageAvailable) { 
cachePath = context.getExternalCacheDir().getPat 
} else { 
cachePath = context.getCacheDir().getPath(); 


J 


return new File(cachePath + File.separator + uniqueN 
} 
@TargetApi(VERSION_CODES.GINGERBREAD ) 
private long getUsableSpace(File path) { 

if (Build.VERSION.SDK_INT => VERSION_CODES.GINGERBRE. 


return path.getUsableSpace(); 


12.3 ”ImageLoader 的 使 用 


人 本 节 将 演示 
如 何 通 过 Image-Loader 来 实现 一 个 照片 墙 的 效果 ， 实 际 上 我 们 会 发 现 ， 
通过 ImageLoader 打 造 一 个 照片 墙 是 轻而易举 的 事情 。 最 后 针对 如 何 提 
高 列表 的 涓 动 流 畅 上 度 这 个 问题 ， 本 市 会 给 出 一 些 针 对 性 的 建议 供 读者 参 


12.3.1 照片 墙 效果 


实现 照片 墙 效果 需要 用 到 GridView， 下 面 先 准备 好 GridView 所 需 的 
布局 文件 以 及 item 的 布局 文件 ， 如 下 所 示 。 





// Gridview 的 布局 文件 
<LinearLayout xmlns:android="http://schemas.android.com/apk/r 
xmins:tools="http://schemas.android.com/tools" 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android: orientation="vertical" 
android: padding="5dp" > 
<GridView 
android: id="@t+id/gridView1" 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 


android: gravity="center" 


android: horizontalSpacing="5dp" 
android: verticalSpacing="5dp" 
android: listSelector="@android:color/transparent" 
android: numColumns="3" 
android:stretchMode="columnWwidth" > 
</GridView> 
</LinearLayout> 
// Gridview 的 item 的 布局 文件 
<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/r 
android: Layout_width="match_parent" 
android: Layout_height="wrap_content" 
android: gravity="center" 
android:orientation="vertical" > 
<com.ryg.chapter_12.ui.SquareImageView 
android: id="@+id/image" 
android: Layout_width="match_parent" 
android: Layout_height="wrap_content" 
android: scaleType="centerCrop" 
android: src="@drawable/image_default" /> 


</LinearLayout> 





也 许 读者 已 经 注意 到 ，GridView 的 item 的 布局 文件 中 并 没有 采用 
ImageView， 而 是 采用 了 一 个 叫 SquareImageView 的 自 定义 控件 。 顾 名 思 
义 ， 它 的 作用 束 是 打造 一 个 正方 形 的 ImageView， 这 样 整 个 照片 墙 看 起 
来 会 比较 整齐 美观 。 要 实现 一 个 宽 、 高 相等 的 ImageView 是 非常 简单 的 

- 件 事 ， 只 需要 在 它 的 onMeasure 方 法 中 稍微 做 一 下 人 处理， 如 下 所 示 。 














public class SquareImageView extends ImageView { 

public SquareImageView(Context context) { 
super (context); 

} 

public SquareImageView(Context context,AttributeSet attr 
super(context,attrs); 

} 

public SquareImageView(Context context,AttributeSet attr 
super (context,attrs,defStyle); 

} 

@Override 

protected void onMeasure(int widthMeasureSpec, int height 


super .onMeasure(widthMeasureSpec, widthMeasureSpec) ; 


可 以 看 出 ， 我 们 在 SquareImageView 的 onMeasure 方 法 中 很 巧妙 地 将 
heightMeasureSpec 蔡 换 为 widthMeasureSpec， 这 样 什么 都 不 用 做 就 可 以 
个 宽 、 高 相等 的 InageView 了 。 关 于 View 的 测量 等 过 程 的 介绍 ， 请 读 
BER RABIAKAR, REARS. 














接着 需要 实现 一 个 BaseAdapter 给 GridView 使 用 ， 下 面 的 代码 展示 了 
ImageAdapter 的 实现 细节 ， 其 中 mUrList 中 存储 的 是 图 片 的 url: 


private class ImageAdapter extends BaseAdapter { 


@Override 


public int getCount() { 





if (mIsGridViewIdle && mCanGetBitmapFromNetwork ) 
imageView.setTag(ur1); 


mImageLoader .bindBitmap(uri, imageView, mIm 


} 


return convertView; 


} 





从 上 述 代码 来 看 ，ImageAdapter 的 实现 过 程 非 常 简 捷 ， 这 几乎 是 最 
简洁 的 BaseAdapter 的 实现 了 。 但 是 简洁 并 不 等 于 简单 ，getView 方 法 中 
核心 代码 只 有 一 句 话 ， 那 就 是 : 
mImageLoader.bindBitmap(uri,image View,mImageWidth,mImageWidth). 
i WbindBitmap 771218 44 Fs HHS R A HY Ar RLE A T 
ImageLoader，ImageLoader 加 载 图 片 以 后 会 把 图 片 自动 设置 给 
imageView， 而 整个 过 程 ， 包 括 内 存 缓存 、 人 磁盘 缓存 以 及 图 片 压缩 等 工 
作 过 程 对 ImageAdapter 来 说 都 是 透明 的 。 在 这 种 设计 思想 下 ， 
ImageAdapter 什 么 也 不 需要 知道 ， 因 此 这 是 一 个 极其 轻 量 级 的 
ImageAdapter。 


接着 将 ImageAdapter 设 置 给 GridView， 如 下 所 示 。 到 此 为 止 一 个 绚 
丽 的 图 片 墙 就 大 功 告 成 了 ， 是 不 是 惊叹 于 如 此 简捷 而 又 优美 的 实现 过 程 
呢 ? 





mImageGridView = (GridView) findViewById(R.id.gridView1); 
mImageAdapter = new ImageAdapter(this); 


mImageGridView.setAdapter(mImageAdapter ) ; 


最 后 ， 看 一 下 我 们 亲手 打造 的 图 片 墙 的 效果 图 ， 如 图 12-1 所 示 。 是 





不 是 看 起 来 很 优美 呢 ? 
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图 12-1 采用 ImageLoader 实 现 的 照片 墙 


另外 ， 本 节 中 的 照片 墙 应 用 首次 运行 时 会 从 网 络 中 加 载 大 量 图 片 ， 
这 会 消耗 若干 MB 的 流量 ， 因 此 建议 首次 运行 时 选择 WiFi 环 境 ， 同 时 程 
序 启 动 时 也 会 有 相应 的 提示 ， 在 非 WiFi 环 境 下 ， 打 开 应 用 时 会 弹出 如 下 
提示 ， 请 读者 运行 时 注意 一 下 ， 避 免 消 耗 过 多 的 流量 。 





if (!mIswifi) { 
AlertDialog.Builder builder = new AlertDialog.Builder (thi 
builder .setMessage(" 初 次 使 用 会 从 网 络 中 下 载 大 概 5MB 的 图 片 ， 确 认 要 
builder .setTitle(" 注 意 ")， 





builder.setPositiveButton(" 是 ",new OnClickListener() { 
@Override 
public void onClick(DialogInterface dialog, int wh 
mCanGetBitmapFromNetWork = true; 


mImageAdapter .notifyDataSetChanged(); 
+); 


builder.setNegativeButton("#",null); 


builder.show(); 


12.3.2 ”优化 列表 的 卡 顿 现象 


这 个 问题 困扰 了 很 多 开发 者 ， 其 实 答案 很 简单 ， 不 要 在 主线 程 中 做 
太 耗 时 的 操作 即 可 提高 请 动 的 流畅 度 ， 可 以 从 三 个 方面 来 说 明 这 个 问 








首先 ， 不 要 在 getView 中 执行 耗 时 操作 。 对 于 上 面 的 例子 来 说 ， 如 
果 直 接 在 getView 方 法 中 加 载 图 片 ， 肯 定 会 导致 卡 顿 ， 因 为 加 载 图 片 是 
一 个 耗 时 的 操作 ， 这 种 操作 必须 通过 异步 的 方式 来 处 理 ， 就 像 
ImageLoader 实 现 的 那样 。 





其 次 ， 控 制 异步 任务 的 执行 频率 。 这 一 点 也 很 重要 ， 对 于 列表 来 

说 ， 仅 仅 在 getView 中 采用 异步 操作 是 不 够 的 。 考 虑 一 种 情况 ， 以 照片 
墙 来 说 ， 在 getView 方 法 中 会 通过 ImageLoader 的 bindBitmap 方 法 来 异步 
加 载 图 片 ， 但 是 如 果 用 户 刻意 地 频繁 上 下 滑动 ， 这 就 会 在 一 瞬间 产生 上 
At BIER» 这 些 异 步 任务 会 造成 线程 池 的 拥堵 并 随即 带 来 大 量 的 UI 
更 新 操作 ， 这 是 没有 意义 的 。 由 于 一 瞬间 存在 大 量 的 UI 更 新 操作 ， 这 些 
UI 操作 是 运行 在 主线 程 的 ， 这 就 会 造成 一 定 程度 的 卡 顿 。 如 何 解 决 这 个 
问题 呢 ? 可 以 考虑 在 列表 滑动 的 时 候 停 止 加 载 图 片 ， 尽 省 这 个 过 程 是 异 
步 的 ， 等 列表 停 下 来 以 后 再 加 载 图 片 仍 然 可 以 获得 展 好 的 用 户 体 验 。 具 
体 实 现时 ， 可 以 给 ListView 或 者 GridView 设 置 setOnScrollListener， 并 在 
OnScrollListener 的 onScrollStateChanged 方 法 中 判断 列表 是 否 处 于 滑动 状 
S&S, WRN TSE MAT, BOR ta. 




















public void onScrollStateChanged(AbsListView view, int scrollS 
if (scrollState == OnScrollListener.SCROLL_STATE_IDLE) { 
mIsGridViewIdle = true; 
mImageAdapter .notifyDataSetChanged(); 
} else { 


mIsGridViewIdle = false; 


然后 在 getView 方 法 中 ， 仅 当 列 表 静 止 时 才能 加 载 图 片 ， 如 下 所 
Ie 
if (mIsGridViewIdle && mCanGetBitmapFromNetWork) { 


imageView.setTag(uri); 


mImageLoader .bindBitmap(uri, imageView, mImagewidth, mImageW 


} 


一 般 来 说 ， 经 过 上 面 两 个 步 又， 列表 都 不 会 有 卡 顿 现象 ， 但 是 在 某 
些 特殊 情况 下 ， 列 表 还 是 会 有 偶尔 的 卡 顿 现象 ， 这 个 时 候 还 可 以 开局 人 硬 
件 加 速 。 绝 大 多 数 情况 下 ， 硬 件 加 速 都 可 以 解决 莫名 的 卡 顿 问题 ， 通 过 
设置 android:hardwareAccelerated="true" 即 可 为 Activity 开 局 便 件 加 速 。 
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我 们 知道 ， 不 管 程序 怎么 写 都 很 难 避 免 不 crash， 当 程序 crash 后 虽 
然 无 法 让 其 再 继续 运行 ， 但 是 如 果 能 够 知道 程序 crash 的 原因 ， 那 么 残 可 
以 修复 错误 。 但 是 很 多 时 候 产品 发 布 后 ， 如 果 用 户 在 使 用 时 发 生 了 
crash， 这 个 crash 信 息 是 很 难 获取 到 的 ， 这 非常 不 利于 一 个 产品 的 持续 
发 展 。 其 实 可 以 通过 CrashHandler 来 监视 应 用 的 crash 信 息 ， 给 程序 设置 
一 个 CrashHandler， 这 样 当 程序 crash 时 就 会 调用 CrashHandler 的 
uncaughtException 方 法 。 在 这 个 方法 中 我 们 可 以 获取 crash 信 息 并 上 传 到 
服务 颈 ， 通 过 这 种 方式 服务 问 台 能 监控 程序 的 运行 状况 了 ， 在 后 续 的 版 
本 开发 中 ， 开 发 人 员 就 可 以 对 一 些 错 误 进 行 修复 了 。 

















在 Android 中 ， 有 一 个 限制 ， 那 就 是 整个 应 用 的 方法 数 不 能 超过 
65536， 盏 则 就 会 出 现 编译 错误 ， 并 且 程 序 也 无 法 成 功 地 安装 到 手机 
上 。 当 项 目 日 益 庞 大 后 这 个 问题 就 比较 容易 遇 到 ，Google 提 供 了 
multidex 方 案 专 门 用 于 解决 这 个 问题 ， 通 过 将 一 个 dex 文 件 拆 分 为 多 个 
dex 文 件 来 避免 单个 dex 文 件 方法 数 越界 的 问题 。 





方法 数 越界 的 妨 一 种 解决 方案 是 动态 加 载 。 动 态 加 载 可 以 直接 加 载 
一 个 dex 形 式 的 文件 ， 将 部 分 代码 打包 到 一 个 单独 的 dex 文 件 中 也 可 以 
征 dex 格 式 的 jar 或 者 apk) ， 并 在 程序 运行 时 根据 需要 去 动态 加 载 dex 中 











的 类 ， 这 种 方式 既 可 以 解决 缓解 方法 数 越界 的 问题 ， 也 可 以 为 程序 提供 
按 需 加 载 的 特性 ， 同 时 这 还 为 应 用 按 模 块 更 新 提供 了 可 能 性 。 











反 编 译 在 应 用 开发 中 用 得 不 是 很 多 ， 但 是 很 多 时 候 我 们 需要 研究 其 
他 产品 的 实现 思路 ， 这 个 时 候 就 需要 反 编 译 了 。 在 Android 中 反 编 译 主 
要 通过 dex2jar 以 及 apktool 来 完成 。dex2jar 可 以 将 一 个 apk 转 成 一 个 jar 
包 ， 这 个 jar 包 再 通过 反 编 译 工 具 jd-gui 来 打开 就 可 以 查看 到 反 编 译 后 的 
Java 代 码 了 。Apktool 主 要 用 于 应 用 的 解 包 和 二 次 打包 ， 实 际 上 通过 
Apktool 的 二 次 打包 可 以 做 很 多 事情 ， 甚 至 是 一 些 违法 的 事情 。 目 前 不 
少 公司 都 有 专门 的 反 编 译 团 队 ， 也 称 逆向 团队 ， 他 们 做 的 事情 会 更 加 深 
入 ， 但 是 对 于 应 用 开发 者 来 说 并 不 需要 了 解 那 么 多 深入 的 逆 加 知识， 
此 本 章 仪 仅 介 绍 一 些 简单 党 用 的 反 编译 方法 。 





13.1 使 用 Cosme 
用 的 crash 信 息 


Android 应 用 不 可 避免 地 会 发 生 crash， 也 称 之 为 朋 溃 ， 无 论 你 的 程 
序 写 得 多 么 完美 ， 总 是 无 法 完全 避免 crash 的 有 发生， 可 能 是 由 于 Android 
系统 底层 的 bug， 也 可 能 是 由 于 不 充分 的 机 型 适 配 或 者 是 糟糕 的 网 络 状 
况 。 当 crash 发 生 时 ， 系 统 会 kil 掉 正在 执行 的 程序 ， 现 象 就 是 内退 或 者 
提示 用 户 程 序 已 停止 运行 ， 这 对 用 户 来 说 是 很 不 友好 的 ， 也 是 开发 者 所 
不 愿意 看 到 的 。 更 糟糕 的 是 ， 当 用 户 发 生 了 crash， 开 发 者 却 无 法 得 知 程 
序 为 何 crash， 即 便 开 发 人 员 想 去 解决 这 个 crash， 但 是 由 于 无 法 知道 用 
户 当时 的 crash 信 息 ， 上 所 以 往往 也 无 能 为 力 。 笠 和 运 的 是 ，Android 提 供 了 
处 理 这 类 问题 的 方法 ， 请 看 下 面 Thread 类 中 的 一 个 方法 
setDefaultUncaughtExceptionHandler: 
































/** 
* Sets the default uncaught exception handler. This handler 
* case any Thread dies due to an unhandled exception. 
* @param handler 
i The handler to set or null. 
a7. 
public static void setDefaultUncaughtExceptionHandler (Uncaugh 
Handler handler) { 
Thread.defaultUncaughtHandler = handler; 





从 方法 的 字面 意义 来 看 ， 这 个 方法 好 像 可 以 设置 系统 的 默认 异常 处 
理 占 ， 其 实 这 个 方法 就 可 以 解决 上 面 所 提 到 的 crash 问 题 。 当 crash 发 生 
的 时 候 ， 系 统 就 会 回调 UncaughtExceptionHandler 的 uncaughtException 方 
法 ， 在 uncaughtException 方 法 中 就 可 以 获取 到 异常 信息 ， 可 以 选择 把 异 
党 信息 存储 到 SD 卡 中 ， 然 后 在 合适 的 时 机 通过 网 络 将 crash 信 息 上 传 到 
服务 器 上 ， 这 样 开发 人 员 束 可 以 分 析 用 户 crash 的 场景 从 而 在 后 面 的 版 本 
中 修复 此 类 crash。 我 们 还 可 以 在 crash 发 生 时 ， 弹 出 一 个 对 话 框 告诉 用 
户 程 序 crash 了 ， 然 后 再 退出 ， 这 样 做 比 内 退 要 温和 一 点 。 

















有 了 上 面 的 分 析 ， 现 在 读者 肯定 知道 获取 应 用 crash 信 息 的 方式 了 。 
首先 需要 实现 一 个 UncaughtExceptionHandler 对 象 ， 在 它 的 
uncaughtException 方 法 中 获取 异常 信息 并 将 其 存储 在 SD 卡 中 或 者 上 传 到 
服务 器 供 开发 人 员 分 析 ， 然 后 调用 Thread 的 setDefaultUncaught- 
ExceptionHandler 方 法 将 它 设置 为 线程 默认 的 异常 处 理 占 ， 由 于 默认 异 
党 处 理 器 是 Thread 类 的 静态 成 员 ， 因 此 它 的 作用 对 象 是 当前 进程 的 所 有 
线程 。 这 么 来 看 监 昕 应 用 的 crash 信 息 实际 上 是 很 简单 的 一 件 事 ， 下 面 是 
一 个 典型 的 异常 处 理 器 的 实现 : 














public class CrashHandler implements UncaughtExceptionHandler 
private static final String TAG = "CrashHandler"; 
private static final boolean DEBUG = true; 
private static final String PATH = Environment.getExtern 
private static final String FILE_NAME = "crash"; 
private static final String FILE_NAME_SUFFIX = ".trace"; 
private static CrashHandler sInstance = new CrashHandler 
private UncaughtExceptionHandler mDefaultCrashHandler ; 


private Context mContext; 











pw.printin(Build.MODEL) ; 
/VCPU 架 构 
pw.print("CPU ABI: "); 
pw.println(Build.CPU_ABT) ; 
t 
private void uploadExceptionToServer() { 


//TODO Upload Exception Message To Your Web Server 


从 上 面 的 代码 可 以 看 出 ， 当 应 用 崩 尝 时 ，CrashHandler 会 将 异常 信 
恩 以 及 设备 信息 写 入 SD 卡 ， 接 着 将 异常 交 给 系统 处 理 ， 系 统 会 帮 我 们 
中 止 程序 ， 如 果 系 统 没 有 默认 的 异常 处 理 机 制 ， 那 么 就 自行 中 止 。 当 然 
也 可 以 选择 将 异常 信息 上 传 到 服务 器 ， 本 节 中 的 CrashHandler 并 没有 实 
现 这 个 逻辑 ， 但 是 在 实际 开发 中 一 般 都 需要 将 异常 信息 上 传 到 服 务 
Ta 








如 何 使 用 上 面 的 CrashHandler 呢 ? 也 很 简单 ， 可 以 选择 在 
Application 初 始 化 的 时 候 为 线程 设置 CrashHandler， 如 下 所 示 。 





public class TestApp extends Application { 
private static TestApp sInstance; 
@Override 
public void onCreate() { 
super.onCreate(); 
SInstance = this; 
// 在 这 里 为 应 用 设置 异常 处 理 ， 然 后 程序 才能 获取 未 处 理 的 异常 


CrashHandler crashHandler = CrashHandler.getInstance 





Zeit EMANE, PEP RAT DAP BOR AD ee SO. LF SI 
程序 crash 了， 同时 还 可 以 很 方便 地 从 服务 器 上 查看 用 户 的 crash 信 息 。 
需要 注意 的 是 ， 代 码 中 被 catch 的 异常 不 会 交 给 CrashHandler 处 理 ， 
CrashHandler 只 能 收 到 那些 未 被 捕获 的 异常 。 下 面 我 们 就 模拟 一 下 发 生 
crash 的 情形 ， 看 程序 是 如 何 处 理 的 ， 如 下 所 示 。 





if (v == mButton) { 
// 在 这 里 模拟 异常 抛 出 情况 ， 人 为 地 抛 出 一 个 运行 时 异常 


(Sh py 


throw new RuntimeException(" 自 定义 异常 : 这 是 自己 抛 出 





} 





在 上 面 的 测试 代码 中 ， 给 按钮 加 一 个 单 击 事件 ， 在 onClick 中 人 为 抛 
出 一 个 运行 时 异常 ， 这 个 时 候 程 序 就 crash 了 ， 看 看 异常 处 理 器 为 我 们 做 
了 什么 。 从 图 13-1 中 可 以 看 出 ， 异 党 处 理 占 为 我 们 创建 了 一 个 日 志文 
件 ， 打 开 日 志文 件 ， 可 以 看 到 手机 的 信息 以 及 异常 发 生 时 的 调用 栈 ， 有 
了 这 些 内 容 ， 开 发 人 员 就 很 容易 定位 问题 了 。 从 图 13-1 中 的 函数 调用 栈 
可 以 看 出 ，CrashActivity 的 28 行 发 生 了 RuntimeException， 再 看 一 下 
CrashActivity 的 代码 ， 发 现 28 行 的 确 抛 出 了 一 个 RuntimeException， 这 说 
明 CrashHandler 已 经 成 功 地 获取 了 未 被 捕获 的 异 弟 信息 ， 从 现在 开始 ， 
为 应 用 加 上 默认 异常 事件 处 理 器 吧 。 








十 





3 (DA 
CrashTest 





© = tl @ 22:59 
log 
2 
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crash2015-05-28 22:58:43.trace 


© 
crash2015-05-28 22:58:43.trace 
2015-05-28 22:58:43 
App Version: 1.0_1 
OS Version: 4.1.1_16 
ee Vendor: Xiaomi 
ou br 22:58:49.trace Model: MI 2S 


CPU ABI: armeabi-v7a 
java.lang.RuntimeException: 自 定义 异常 : 这 
是 自己 抛 出 的 异常 
at com.ryg.crashtest.CrashActivity. 
onClick(CrashActivity.java:29) 
at android.view. View. performClick(View. 
java:4171) 
at android.view. View$PerformClick. 
run(View.java:17097) 
at android.os.Handler. 


at android.os.Handler. 


Q 


handleCallback(Handler.java:6 15) 
搜索 


dispatchMessage(Handler.java:92) 

at android.os.Looper.loop(Looper.java:137) 
at android.app.ActivityThread. 
main(ActivityThread.java:4914) 

at java.lang.reflect.Method. 
invokeNative(Native Method) 
图 13-1 





at java.lang.reflect.Method.invoke(Method. 


CrashHandler 获 取 的 异常 1 


= AL 
aw 


13.2 ”使 用 multidex 来 解决 方法 数 


越界 


在 Android 中 单个 dex 文 件 所 能 够 包含 的 最 大 方法 数 为 65536， 这 包 
FrameWork、 依 赖 的 jar 包 以 及 应 用 本 身 的 代码 中 的 所 有 方 
法 。65536 是 一 个 很 大 的 数 ， 一 般 来 说 一 个 简单 应 用 的 方法 数 的 确 很 难 
达到 65536， 但 是 对 于 一 些 比较 大 型 的 应 用 来 说 ，65536 就 很 容易 达到 
了 。 当 应 用 的 方法 数 达到 65536 后 ， 编 译 器 束 无 法 完成 编译 工作 并 抛 出 
类 似 下 面 的 异常: 


含 Android 





UNEXPECTED TOP-LEVEL EXCEPTION: 


com.android.dex.DexIndexOverflowException: method ID not in [ 


65536 
at 
at 
at 
at 
at 
at 
at 
at 
at 
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com. 
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.android. 





android. 
android. 
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android. 
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android. 
android. 


android. 


dx 


dx. 
dx. 
dx. 
dx. 
dx. 
dx. 
dx. 
dx. 
dx. 


.merge. 


merge. 
merge. 
merge. 


merge. 


DexMerger$6.updateIndex(DexMerger 
DexMerger$IdMerger .mergeSorted(De 
DexMerger .mergeMethodIds(DexMerge 
DexMerger .mergeDexes(DexMerger.ja 


DexMerger .merge(DexMerger. java:18 


command. dexer .Main.mergeLibraryDexBuffe 
command.dexer .Main. runMonoDex(Main. java 
command.dexer .Main.run(Main. java: 246) 
command.dexer .Main.main(Main.java:215) 


command.Main.main(Main. java:106) 


另外 一 种 情况 有 所 不 同 ， 有 时 候 方法 数 并 没有 达到 65536， 并 且 编 





译 器 也 正常 地 完成 了 编译 工作 ， 但 是 应 用 在 低 版 本 手机 安装 时 异常 中 
止 ， 异常 信息 如 下 : 


E/dalvikvm: Optimization failed 
E/installd: dexopt failed on '/data/dalvik-cache/data@app@com 
multidextest-2.apk@classes.dex' res = 65280 


为 什么 会 出 现 这 种 情况 呢 ? 其 实 是 这 样 的 ，dexopt 是 一 个 程序 ， 应 
用 在 安装 时 ， 系 统 会 通过 dexopt 来 优化 dex 文 件 ， 在 优化 过 程 中 dexopt 采 
用 一 个 固定 大 小 的 缓冲 区 来 存储 应 用 中 所 有 方法 的 信息 ， 这 个 缓冲 区 就 
是 LinearAlloc。LinearAlloc 绥 冲 区 在 新 版 本 的 Android 系 统 中 其 大 小 是 
8MB 或 者 16MB， 但 是 在 Android 2.2 和 2.3 中 却 只 有 5MB， 当 待 安装 的 apk 
中 的 方法 数 比 较 多 时 ， 尽 管 它 还 没有 达到 65536 这 个 上 限 ， 但 是 它 的 存 
储 空间 仍然 有 可 能 超出 5MB， 这 种 情况 下 dexopt 程 序 就 会 报错 ， 从 而 导 
致 安装 失败 ， 这 种 情况 主要 在 2.x 系 列 的 手机 上 出 现 。 





可 以 看 到 ， 不 管 是 编译 时 方法 数 越界 还 是 安装 时 的 dexopt 错 误 ， 它 
们 都 给 开发 过 程 带 来 了 很 大 的 困扰 。 从 目前 的 Android 版 本 的 市 场 占 有 
率 来 说 ，Android 3.0 以 下 的 手机 仍然 占据 着 不 到 10% 的 比率 ， 目 前 主流 
的 应 用 都 不 可 能 放弃 Android 3.0 以 下 的 用 户 ， 对 于 这 些 应 用 来 说 ， 方 法 
数 越界 就 是 一 个 必须 要 解决 的 问题 了 。 


如 何 解决 方法 数 越界 的 问题 呢 ? 我 们 首先 想到 的 肯定 是 删除 无 用 的 
代码 和 第 三 方 库 。 没 错 ， 这 的 确 是 必须 要 做 的 工作 ， 但 是 很 多 情况 下 即 
使 删除 了 无 用 的 代码 ， 方 法 数 仍然 越界 ， 这 个 时 候 该 怎么 办 呢 ? 针对 这 
个 问题 ， 之 前 很 多 应 用 都 会 考虑 采用 插件 化 的 机 制 来 动态 加 载 部 分 
dex， 通 过 将 一 个 dex 拆 分 成 两 个 或 多 个 dex， 这 就 在 一 定 程度 上 解决 了 
方法 数 越界 的 问题 。 但 是 插件 化 是 一 套 重 量 级 的 技术 方案 ， 并 且 其 兼容 























性 问题 往往 较 多 ， 从 单纯 解决 方法 数 越界 的 角度 来 说 ， 插 件 化 并 不 是 一 
个 非常 适合 的 方案 ， 关 于 插件 化 的 意义 将 在 第 13.3 节 中 进行 介绍 。 为 了 
解决 这 个 问题 ，Google 在 2014 年 提出 了 multidex 的 解决 方案 ， 通 过 
multidex 可 以 很 好 地 解决 方法 数 越界 的 问题 ， 并 且 使 用 起 来 非常 简单 。 


在 Android 5.0 以 前 使 用 multidex 需 要 引入 Google 提 供 的 android- 
support-multidex.jar 这 个 jar 包 ， 这 个 jar 包 可 以 在 Android ” SDK 目录 下 的 
extras/android/support/multidex/library/ libs 下 面 找 到 。 从 Android 5.0 开 

台 ，Android 默 认 支持 了 multidex， 它 可 以 从 apk 中 加 载 多 个 dex 文 件 。 
Multidex 方 案 主要 是 针对 AndroidStudio 和 Gradle 编 译 环 境 的 ， 如 果 是 
Eclipse 和 ant 那 就 复杂 一 些 ， 而 且 由 于 AndroidStudio 作 为 官方 IDE 其 最 终 
会 完全 蔡 代 Eclipse ADT， 因 此 本 市 中 也 不 再 介绍 Eclipse 中 配置 multidex 
的 细节 了 。 


在 AndroidStudio 和 Gradle 编 译 环 境 中 ， 如 果 要 使 用 multidex， 首 先 
要 使 用 Android SDK Build Tools 21.1 及 以 上 版 本 ， 接 着 修改 工程 中 app 目 
录 下 的 build.gradle 文 件 ， 在 defaultConfig 中 添加 multiDexEnabled ”true 这 
个 配置 项 ， 如 下 所 示 。 关 于 如 何 使 用 AndroidStudio 和 Gradle 请 读者 自行 


查看 相关 资料 ， 这 里 不 再 介绍 。 


android { 
compileSdkVersion 22 
buildToolsVersion "22.0.1" 
defaultConfig { 
applicationId "com.ryg.multidextest" 
minSdkVersion 8 
targetSdkVersion 22 


versionCode 1 





接着 还 需要 在 dependencies 中 添加 multidex 的 依赖 : compile 
'com.android.support: multidex:1.0.0'"， 如 下 所 示 。 





最 终 配置 完成 的 build.gradle 文 件 如 下 所 示 ， 其 中 加 粗 的 部 分 是 专门 
为 multidex 所 添加 的 配置 项 : 








经 过 了 上 面 的 过 程 ， 还 需要 做 另 一 项 工作 ， 那 就 是 在 代码 中 加 入 去 
持 multidex 的 功能 ， 这 个 过 程 是 比较 简单 的 ， 有 三 种 方案 可 以 选 。 


第 一 种 方案 ， 在 manifest 文 件 中 指定 Application 为 
MultiDexApplication， 如 下 所 示 。 





android: label="@string/app_name" 


android: theme="@style/AppTheme" > 


</application> 


第 三 种 方案 ， 让 应 用 的 Application 继 承 MultiDexApplication， 比 
OU: 


public class TestApplication extends MultiDexApplication { 


第 三 种 方案 ， 如 果 不 想 让 应 用 的 Application 继 承 
MultiDexApplication， 还 可 以 选择 重 写 Application 的 attachBaseContext 方 
法 ， 这 个 方法 比 Application 的 onCreate 要 先 执行 ， 如 下 所 示 。 


public class TestApplication extends Application { 
@Override 
protected void attachBaseContext(Context base) { 
super.attachBaseContext (base); 


MultiDex.install(this); 


现在 所 有 的 工作 都 已 经 完成 了 ， 可 以 发 现 应 用 不 但 可 以 编译 通过 了 
并 且 还 可 以 在 Android 2.x 手 机 上 而 正常 安 儿 了。 可 以 发 现 ，multidex 使 
用 起 来 还 是 很 简单 的 ， 对 于 一 个 使 用 multidex 方 案 的 应 用 ， 采 用 了 上 面 
的 配置 项 ， 如 果 这 个 应 用 的 方法 数 没有 越界 ， 那 么 Gradle 并 不 会 生成 多 








个 dex 文 件 ， 如 果 方 法 数 越界 后 ，Gradle 就 会 在 apk 中 打包 2 个 或 多 个 dex 
文件 ， 具 体会 打包 和 多少 个 dex 文 件 要 看 当前 项 目的 代码 规模 。 图 13-2 展 
示 了 采用 multidex 方 案 的 apk 中 多 个 dex 的 分 布 情形 。 


app-debug.apk © 


app-debug.apk 


| * | 





图 13-2 普通 apk 和 采用 multidex 方 案 的 apk 


上 面 介绍 的 是 multidex 默 认 的 配置 ， 还 可 以 通过 build.gradle 文 件 中 
一 些 其 他 配置 项 来 定制 dex 文 件 的 生成 过 程 。 在 有 些 情况 下 ， 可 能 需要 
指定 主 dex 文 件 中 所 要 包含 的 类 ， 这 个 时 候 就 可 以 通过 --main-dex-list 选 
项 来 实现 这 个 功能 。 下 面 是 修改 后 的 build.gradle 文 件 ， 在 里 面 添加 了 
afterEvaluate 区 域 ， 在 afterEvaluate 区 域内 部 采用 了 --main-dex-list 选 项 来 
指定 主 dex 中 要 包含 的 类 ， 如 下 所 示 。 

















apply plugin: 'com.android.application' 
android { 
compileSdkVersion 22 
buildToolsVersion "22.0.1" 
defaultConfig { 
applicationId "com.ryg.multidextest" 
minSdkVersion 8 


targetSdkVersion 22 


versionCode 1 
versionName "1.0" 
// enable multidex support 
multiDexEnabled true 
} 
buildTypes { 
release { 
minifyEnabled false 
proguardFiles getDefaultProguardFile('proguard-a 


'proguard-rules.pro' 


I 


afterEvaluate { 

println "afterEvaluate" 

tasks.matching { 
it.name.startsWith('dex' ) 

}.each { dx -> 
def listFile = project.rootDir.absolutePath + '/app/ 
println "root dir:" + project.rootDir.absolutePath 
println "dex task found: " + dx.name 
if (dx.additionalParameters == null) { 


dx.additionalParameters = [] 


} 
dx.additionalParameters += '--multi-dex' 
dx.additionalParameters += '--main-dex-list=' + list 


dx.additionalParameters += '--minimal-main-dex' 


} 


dependencies { 
compile fileTree(dir: 'libs',include: ['*.jar']) 
compile 'com.android.support:appcompat-v7:22.1.1' 


compile 'com.android.support:multidex:1.0.0' 


在 上 面 的 配置 文件 中 ，--multi-dex 表 示 当 方法 数 越界 时 则 生成 多 个 
dex 文 件 ，--main-dex-list 指 定 了 要 在 主 dex 中 打包 的 类 的 列表 ，-- 
minimal-main-dex 表 明 只 有 --main-dex-list 所 指定 的 类 才能 打包 到 主 dex 
中 。 它 的 输入 是 一 个 文件 ， 在 上 面 的 配置 中 ， 它 的 输入 是 工程 中 app 目 
录 下 的 maindexlist.txt 这 个 文件 ， 在 maindexlist.txt 中 则 指定 了 一 系列 的 
类 ， 所 有 在 maindexlist.txt 中 的 类 都 会 被 打包 到 主 dex 中 。 注 意 
maindexjlist.txt 这 个 文件 名 是 可 以 修改 的 ， 但 是 它 的 内 容 必 须要 遵守 一 定 
的 格式 ， 下 面 是 一 个 示例 ， 这 种 格式 是 固定 的 。 








com/ryg/multidextest/TestApplication.class 
com/ryg/multidextest/MainActivity.class 

// multidex 
android/support/multidex/MultiDex.class 
android/support/multidex/MultiDexApplication.class 
android/support/multidex/MultiDexExtractor.class 
android/support/multidex/MultiDexExtractor$1.class 
android/support/multidex/MultiDex$V4.class 
android/support/multidex/MultiDex$V14.class 


android/support/multidex/MultiDex$V19.class 


android/support/multidex/ZipUtil.class 


android/support/multidex/ZipUtil$CentralDirectory.class 





程序 编译 后 可 以 反 编 译 apk 中 生成 的 主 dex 文 件 ， 可 以 发 现 主 dex 文 
件 的 确 只 有 maindexlist.txt 文 件 中 所 声明 的 类 ， 读 者 可 以 自行 尝试 。 
maindexlist.txt 这 个 文件 很 多 时 候 都 是 可 以 通过 脚本 来 自动 生成 内 容 的 ， 
这 个 脚本 需要 根据 当前 的 项 目 自行 实现 ， 如 有 果 不 玉 用 脚本 ， 人 工 编辑 
maindexlist.txt 也 是 可 以 的 。 














需要 注意 的 是 ，multidex 的 jar 包 中 的 9 个 类 必须 也 要 打包 到 主 dex 
中 ， 人 否则 程序 运行 时 会 抛 出 异常 ， 告 知 无 法 找到 multidex 相 关 的 类 。 这 
是 因为 Application 对 象 被 创建 以 后 会 在 attachBaseContext 方 法 中 通过 
MultiDex.install(this) 来 加 载 其 他 dex 文 件 ， 这 个 时 候 如 果 MultiDex 相 关 的 
类 不 在 主 dex 中 ， 很 显然 这 些 类 是 无 法 被 加 载 的 ， 那 么 程序 执行 就 会 出 
错 。 同 时 由 于 Application 的 成 员 和 代码 块 会 先 于 attachBaseContext 方 法 
而 初始 化 ， 而 这 个 时 候 其 他 dex 文 件 还 没有 被 加 载 ， 因 此 不 能 在 
Application 的 成 员 以 及 代码 块 中 访问 其 他 dex 中 的 类 ， 人 否则 程序 也 会 因为 
无 法 加 载 对 应 的 类 而 中 止 执 行 。 在 下 面 的 代码 中 ， 模 拟 了 这 种 场景 ， 在 
Application 的 成 员 中 使 用 了 其 他 dex 文 件 中 的 类 View1。 








public class TestApplication extends Application { 
private View1 view1 = new View1(); 
@Override 
protected void attachBaseContext(Context base) { 
super.attachBaseContext(base); 


MultiDex.install(this); 


上 面 的 代码 会 导致 如 下 运行 错误 ， 因 此 在 实际 开发 中 要 避免 这 个 错 


E/AndroidRuntime: FATAL EXCEPTION: main 

Process: com.ryg.multidextest,PID: 12709 

java.lang.NoClassDefFoundError: com.ryg.multidextest.ui.View1 
at com.ryg.multidextest.TestApplication.<init>(Te 
at java.lang.Class.newInstanceImpl(Native Method) 
at java.lang.Class.newInstance(Class.java:1208) 
at android.app.Instrumentation.newApplication(Ins 
at android.app.Instrumentation.newApplication(Ins 


at android.app.LoadedApk.makeApplication(LoadedAp 


Multidex 方 法 虽然 很 好 地 解决 了 方法 数 越界 这 个 问题 ， 但 它 也 是 有 
一 些 局 限 性 的 ， 下 面 是 采用 multidex 可 能 带 来 的 问题 : 


C1) 应 用 局 动 速度 会 降低 。 由 于 应 用 启动 时 会 加 载 额 外 的 dex 文 
件 ， 这 将 导致 应 用 的 局 动 速度 降低 ， 甚 至 可 能 出 现 ANR 现 象 ， 尤 其 是 其 
他 dex 文 件 较 大 的 时 候 ， 因 此 要 避免 生成 较 大 的 dex 文 件 。 


(2) 由 于 Dalvik linearAlloc 的 bug， 这 可 能 导致 使 用 multidex 的 应 用 
无 法 在 Android 4.0 以 前 的 手机 上 运行 ， 因 此 需要 做 大 量 的 兼容 性 测试 。 
同时 由 于 Dalvik linearAlloc 的 bug， 有 可 能 出 现 应 用 在 运行 中 由 于 采用 了 
multidex 方 案 从 而 产生 大 量 的 内 存 消耗 的 情况 ， 这 会 导致 应 用 朋 溃 。 














在 实际 的 项 目 中 ，《1) 中 的 现象 是 客观 存在 的 ， 但 是 2) 中 的 现 
象 目前 极 少 遇 到 ， 综 合 来 说 ，multidex 还 是 一 个 解决 方法 数 越界 非常 好 








的 方案 ， 可 以 在 实际 项 目 中 使 用 。 


13.3 Android 的 动态 加 载 技 术 


动态 加 载 技术 〈 也 叫 插件 化 技术 ) 在 技术 驱动 型 的 公司 中 扮演 着 相 
当 重 要 的 角色 ， 当 项 目 越 来 越 庞大 的 时 候 ， 需 要 通过 插件 化 来 减轻 应 用 
的 内 存 和 CPU 占用 ， 还 可 以 实现 热 插 拔 ， 即 在 不 发 布 新 版 本 的 情况 下 更 
新 某 些 模块 。 动 态 加 载 是 一 项 很 复杂 的 技术 ， 这 里 主要 介绍 动态 加 载 技 
术 中 的 三 个 基础 性 问题 ， 至 于 完整 的 动态 加 载 技 术 的 实现 请 参考 笔者 发 
起 的 开源 插件 化 框架 DL: https://github.com/singwhatiwanna/dynamic- 
load-apk。 项 目 期 间 有 多 位 开发 人 员 一 起 贡献 代码 。 





不 同 的 插件 化 方案 各 有 各 的 特色 ， 但 是 它们 都 必须 要 解决 三 个 基础 
性 问题 : 资源 访问 、Activity 生 命 周 期 的 管理 和 ClassLoader 的 管理 。 在 
介绍 它们 之 前 ， 首 先 要 明白 宿主 和 插件 的 概念 ， 宿 主 是 指 普 通 的 apk， 
而 插件 一 般 是 指 经 过 处 理 的 dex 或 者 apk， 在 主流 的 插件 化 框架 中 多 采用 
经 过 特殊 处 理 的 apk 来 作为 插件 ， 处 理 方式 往往 和 编译 以 及 打包 环节 有 
关 ， 男 外 很 多 插件 化 框架 都 需要 用 到 代理 Activity 的 概念 ， 插 件 Activity 
的 启动 大 多 数 是 借助 一 个 代理 Activity 来 实现 的 。 











1. 资源 访问 


我 们 知道 ， 香 主 程序 调 起 未 安装 的 插件 apk， 一 个 很 大 的 问题 束 是 
资源 如 何 访 问 ， 有 共 体 来 说 吏 是 插件 中 凡是 以 R 开 头 的 资源 都 不 能 访问 
了 。 这 是 因为 宿主 程序 中 并 没有 插件 的 资源 ， 所 以 通过 R 来 加 载 插件 的 
资源 是 行 不 通 的 ， 程 序 会 抛 出 异 币 : 无 法 找到 茶 茶 id 所 对 应 的 资源 。 针 
对 这 个 问题 ， 有 人 提出 了 将 插件 中 的 资源 在 宾主 程序 中 也 预 置 一 份 ， 这 
虽然 能 解雇 问题， 但 是 这 样 就 会 产生 一 些 竞 喘 。 首 先 ， 这 样 就 需要 牡 主 
































和 插件 同时 持 有 一 份 相同 的 资源 ， 增 加 了 和 宿主 apk 的 大 小 ;其 次 ， 在 这 
种 模式 下 ， 每 次 发 布 一 个 插件 都 需要 将 资源 复制 到 条 主 程序 中 ， 这 意味 
着 每 及 布 一 个 插件 都 要 更 新 一 下 箱 主 程序 ， 这 就 和 插件 化 的 思想 相 违 背 
了 。 因 为 插件 化 的 目的 就 是 要 减 小 宿主 程序 apk 包 的 大 小 ， 同 时 降低 宿 
主 程序 的 更 新 频 京 并 做 到 自由 六 载 模块 ， 所 以 这 种 方法 不 可 取 ， 它 限制 
了 插件 的 线 上 更 新 这 一 重要 特性 。 还 有 人 提供 了 另 一 种 方式 ， 首 先 将 插 
件 中 的 资源 解压 出 来 ， 然 后 通过 文件 流 去 读 取 资源 ， 这 样 做 理论 上 是 可 
行 的 ， 但 是 实际 操作 起 来 还 是 有 很 大 难度 的 。 首 先 不 同 资源 有 不 同 的 文 
件 流 格式 ， 比 如 图 片 、XML 等 ， 其 次 针对 不 同 设备 加 载 的 资源 可 能 是 

不 一 样 的 ， 如 何 选择 合适 的 资源 也 是 一 个 需要 解决 的 问题 ， 基 于 这 两 

点 ， 这 种 方法 也 不 建议 使 用 ， 因 为 它 实 现 起 来 有 较 大 难度 。 为 了 方便 地 
对 插件 进行 资源 管理 ， 下 面 给 出 一 种 合理 的 方式 。 














我 们 知道 ，Activity 的 工作 主要 是 通过 ContextImpl 来 完成 的 ， 
Activity 中 有 一 个 叫 mBase 的 成 员 变 量 ， 它 的 类 型 惑 是 ContextImp1。 注 意 
到 Context 中 有 如 下 两 个 抽象 方法 ， 看 起 来 是 和 资源 有 关 的 ， 实 际 上 
Context 就 是 通过 它们 来 获取 资源 的 。 这 两 个 抽象 方法 的 真正 实现 在 
ContextImpl 中 ， 也 束 是 说 ， 只 要 实现 这 两 个 方法 ， 束 可 以 解决 资源 问题 
Ja 























/** Return an AssetManager instance for your application's pa 
public abstract AssetManager getAssets(); 
/** Return a Resources instance for your application's packa 


public abstract Resources getResources(); 





下 面 给 出 有 具体 的 实现 方式 ， 首 先 要 加 载 apk 中 的 资源 ， 如 下 所 示 。 


protected void loadResources() { 


try { 
AssetManager assetManager = AssetManager.class.ne 
Method addAssetPath = assetManager.getClass().get 
addAssetPath.invoke(assetManager,mDexPath) ; 
mAssetManager = assetManager; 

} catch (Exception e) { 
e.printStackTrace(); 

} 

Resources superRes = super.getResources(); 

mResources = new Resources(mAssetManager, superRes.getDisp 

superRes.getConfiguration()); 
mTheme = mResources.newTheme(); 


mTheme.setTo(super.getTheme()); 


从 loadResources0O 的 实现 可 以 看 出 ， 加 载 资源 的 方法 是 通过 反射 ， 
通过 调用 AssetManager 中 的 addAssetPath 方 法 ， 我 们 可 以 将 一 个 apk 中 的 
资源 加 载 到 Resources 对 象 中 ， 由 于 addAssetPath 是 隐藏 API 我们 无 法 直接 
调用 ， 所 以 只 能 通过 反射 。 下 面 是 它 的 声明 ， 通 过 注释 我 们 可 以 看 出 ， 
传递 的 路 径 可 以 是 zip 文 件 也 可 以 是 一 个 资源 目录 ， 而 apk 束 是 一 个 zip， 
所 以 直接 将 apk 的 路 径 传 给 它 ， 资 源 就 加 载 到 AssetManager 中 了 。 然 后 
再 通过 AssetManager 来 创建 一 个 新 的 Resources 对 象 ， 通 过 这 个 对 象 我 们 
就 可 以 访问 插件 apk 中 的 资源 了 ， 这 样 一 来 问题 就 解决 了 。 





[hes 
* Add an additional set of assets to the asset manager. Thi 


* either a directory or ZIP file. Not for use by applicatio 





接着 在 代理 Activity 中 实现 getAssets0 和 getResources0)， 如 下 所 示 。 
关于 代理 Activity 的 含义 请 参看 DL 开源 插件 化 框架 的 实现 细节 ， 这 里 不 
再 详细 描述 了 。 





通过 上 述 这 两 个 步骤 ， 就 可 以 通过 R 来 访问 插件 中 的 资源 了 。 


2. Activity 生 命 周期 的 管理 


管理 Activity 和 后 命 周 期 的 方式 各 种 各 样 ， 这 里 只 介绍 两 种 : 反射 方 
式 和 接口 方式 。 反 射 的 方式 很 好 理解 ， 首 先 通过 Java 的 反射 去 获取 
Activity 的 各 种 生命 周期 方法 ， 比 如 onCreate、onStart、onResume 等 ， 然 
后 在 代理 Activity 中 去 调用 插件 Activity 对 应 的 生命 周期 方法 即 可 ， 如 下 
所 示 。 





} 


super .onPause(); 


使 用 反射 来 管理 插件 Activity 的 生命 周期 是 有 缺点 的 ， 一 方面 是 反 
射 代码 写 起 来 比较 复杂 ， 男 一 方面 是 过 多 使 用 反射 会 有 一 定 的 性 能 
销 。 下 面 介 绍 接口 方式 ， 接 口 方式 很 好 地 解决 了 反射 方式 的 不 足 之 处 ， 
这 种 方式 将 Activity 的 生命 周期 方法 提取 出 来 作为 一 个 接口 〈 比 如 叫 
DLPlugin) ， 然 后 通过 代理 Activity 去 调用 插件 Activity 的 生命 周期 方 
法 ， 这 样 就 完成 了 插件 Activity 的 生命 周期 管理 ， 并 且 没 有 采用 反射 ， 
这 就 解决 了 性 能 问题 。 


声明 


public interface 


public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 


void 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 


void 








同时 接口 的 声明 也 比较 简单 ， 下 面 是 DLPlugin 的 


DLPlugin { 

onStart(); 

onRestart(); 

onActivityResult(int requestCode, int resultc 
onResume(); 

onPause(); 

onStop(); 

onDestroy(); 

onCreate(Bundle savedInstanceState) ; 
setProxy(Activity proxyActivity,String dexPa 
onSaveInstanceState(Bundle outState); 
onNewIntent(Intent intent); 


onRestoreInstanceState(Bundle savedInstanceS 


boolean onTouchEvent(MotionEvent event); 


在 代理 Activity 中 只 需要 按 如 下 方式 即 可 调用 插件 Activity 的 生命 周 
期 方法 ， 这 就 完成 了 插件 Activity 的 生命 周期 的 管理 。 





通过 上 述 代码 应 该 不 难 理解 接口 方式 对 插件 Activity 生 命 周期 的 管 
理 思 想 ， 其 中 mRemoteActivity 就 是 DLPlugin 的 实现 。 


3. 插件 ClassLoader 的 管理 





为 了 更 好 地 对 多 插件 进行 文 持 ， 需 要 合理 地 去 管理 各 个 插件 的 
DexClassoader， 这 样 同一 个 插件 就 可 以 采用 同一 个 ClassLoader 去 加 载 
类 ， 从 而 避免 了 多 个 ClassLoader 加 载 同 一 个 类 时 所 引发 的 类 型 转换 错 
误 。 在 下 面 的 代码 中 ， 通 过 将 不 同 插件 的 ClassLoader 存 储 在 一 个 
HashMap 中 ， 这 样 就 可 以 保证 不 同 插 件 中 的 类 彼此 互 不 干扰 。 





public class DLClassLoader extends DexClassLoader { 


private static final String TAG = "DLClassLoader"; 


private static final HashMap<String,DLClassLoader> mPlug 


= new HashMap<String, DLClassLoader>()/; 


protected DLClassLoader(String dexPath,String optimizedD 


super (dexPath, optimizedDirectory, libraryPath, parent) 


t 
jp eres 


* return a available classloader which belongs to diffe 


“y 


public static DLClassLoader getClassLoader(String dexPat 


context,ClassLoader parentLoader) { 


DLClassLoader dLClassLoader = mPluginClassLoaders.ge 


if (dLClassLoader != null) 


return dLClassLoader; 


File dexOutputDir = context.getDir("dex",Context.MOD 


final String dexOutputPath = dexOutputDir.getAbsolut 


dLClassLoader = new DLClassLoader (dexPath, dexOutputP 


parentLoader ); 
mPluginClassLoaders.put(dexPath, dLClassLoader ); 


return dLClassLoader; 


t 
t 
事实 上 插件 化 的 技术 细节 非常 多 ， 这 绝 非 一 个 章节 的 内 容 押 能 描述 
的 ， 男 外 插件 化 作为 一 种 核心 拉 术 ， 雷 要 开发 者 有 较 深 的 开 友 功 奔 


清楚 

1B xe 
ee le ie ar 
感性 的 了 解 ， 细 市 上 还 需要 读者 自己 去 钻研 ， 也 可 以 通过 DL 插件 化 框 
JAH 
AN 


去 深入 地 学 习 。 


13.4 反 编 译 人 初步 


反 编 译 属于 逆 同 工程 中 的 一 种 ， 反 编译 有 很 多 高 级 的 手段 和 工具 ， 
本 节 只 是 为 了 让 读者 掌握 初级 的 反 编 译 手 段 ， 毕 竞 对 于 一 个 不 是 专业 做 
逆向 的 开发 人 员 来 说 ， 的 确 没 有 必要 人 花 大 量 时 间 去 研究 反 编 译 的 一 些 高 
级 技巧 。 本 贡 主 要 介绍 两 方面 的 内 容 ， 一 方面 是 介绍 使 用 dex2jar 和 jd- 
guij 来 反 编 译 apk 的 方式 ， 另 一 方面 是 介绍 使 用 apktool 来 对 apk 进 行 二 次 打 
包 的 方式 。 下 面 是 这 三 个 反 编 译 工 具 的 下 载 地 址 。 














apktool: http://ibotpeaches.github.io/Apktool/ 
dex2jar: https://github.com/pxb1988/dex2jar 


jd-gui: http://jd.benow.ca/ 


13.4.1 使 用 dex2jar 和 jd-gui 反 编译 
apk 


Dex2jar 和 jd-gui 在 很 多 操作 系统 上 都 可 以 使 用 ， 本 市 只 介绍 它们 在 
Windows 和 Linux 上 的 使 用 方式 。Dex2jar 是 一 个 将 dex 文 件 转 换 为 jar 包 的 
工具 ， 它 在 Windows 和 Linux 上 都 有 对 应 的 版 本 ，dex 文 件 来 源 于 apk， 将 
apk 通 过 zip 包 的 方式 解压 缩 即 可 提取 出 里 面 的 dex 文 件 。 有 了 jar 包 还 不 
行 ， 因 为 jar 包 中 都 是 class 文 件 ， 这 个 时 候 还 需要 jd-gui 将 jar 包 进一步 转 
换 为 Java 代 码 ，jd-gui 仍 然 支 持 Windows 和 Linux， 不 管 是 dex2jar 还 是 jd- 
gui， 它 们 在 不 同 的 操作 系统 中 的 使 用 方式 都 是 一 致 的 。 


Dex2jar 是 命令 行 工具 ， 它 的 使 用 方式 如 下 : 


Linux (Ubuntu): ./dex2jar.sh classes.dex 


Windows: dex2jar.bat classes.dex 








Jd-gui 是 图 形 化 工具 ， A ei 
jar 包 的 源码 。 下 面 做 一 个 示例 ， 通 过 dex2jar 和 jd-gui 来 反 编译 13.1 节 中 的 
示例 程序 的 apk。 首 先 将 apk 解 压 后 提取 出 classes.dex 文 件 ， 接 着 通过 
dex2jar 反 编译 classes.dex， 人 然后 通过 jd-gui 来 打开 反 编 译 后 的 jar 包 ， 如 图 
13-3 所 示 。 可 以 发 现 反 编 译 后 的 结果 和 第 13.1 节 中 CrashActivity 的 源 代码 
己 经 比较 接近 了 ， 通 过 左边 的 采 单 可 以 查看 其 他 类 的 反 编译 结果 。 
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H-H android.support.v4 










日 - 骨 com.ryg.crashtest 
由 - 因 BuildConfig 

由 - 国 CrashActivity 
a {J} CrashHandler 
由 - D R 

-D TestApp 





package com.ryg.crashtest; 





import android.app.Activity; | 
| 












public class CrashActivity extends Activity 
implements View.OnClickListener 





private Button mButton; 
private void initView() 


Button localButton = (Button) findViewById (2131296256) ; 
this.mButton = localButton; 
this. mButton.setOnClickListener (this); 

} 


public void onClick(View paramView) 
{ 
Button localButton = this.mButton; 
if (paramView != localButton) 
return; 
throw new RuntimeException(" 自 定义 异常 : Zaan HRA"); 
} 


protected void onCreate (Bundle paramBundle) 
{ 
super. onCreate (paramBundle) ; 
setContentView (2130903040); 
initView (); 


} 











} 




















图 13-3 使 用 jd-gui 反 编译 jar 包 


13.4.2 ”使 用 apktool 对 apk 进 行 二 次 打 
包 


在 13.4.1 节 中 介绍 了 dex2jar 和 jd-gui 的 使 用 方式 ， 通 过 它们 可 以 将 一 
个 dex 文 件 反 编译 为 Java 代 码 ， 但 是 它们 无 法 反 编 译 出 apk 中 的 二 进 制 数 
据 资 源 ， 但 是 采用 apktool 就 可 以 做 到 这 一 点 。apktool 男 外 一 个 常见 的 用 
途 是 二 次 打包 ， 也 就 是 常见 的 山寨 版 应 用 。 将 官方 应 用 二 次 打包 为 山 宗 
应 用 ， 这 是 一 种 不 被 提倡 的 行为 ， 甚 至 是 违法 的 ， 建 议 开 发 者 不 要 去 这 
么 做 ， 但 是 掌握 以 下 二 次 打包 的 技术 对 于 个 人 技术 的 提高 还 是 很 有 意义 
的 。apktool 同 样 有 多 个 版 本 ， 这 里 同样 只 介绍 Windows 版 和 Linux 版 ， 
apktool 是 一 个 命令 行 工具 ， 它 的 使 用 方式 如 下 所 示 。 这 里 仍然 拿 13.1 市 
中 的 示例 程序 为 例 ， 假 定 apk 的 文件 名 为 CrashTest.apk。 























Linux (Ubuntu) 
解 包 : ./apktool d -f CrashTest.apk CrashTest. 
二 次 打包 : ./apktool b CrashTest CrashTest-fake.apk « 


签名 : java -jar signapk.jar testkey.x509.pem testkey.pk8 CrashTest- 
fake.apk CrashTest-fake-signed.apk. 


Windows 


解 包 : apktool.bat d -f CrashTest.apk CrashTest. 


二 次 打包 : apktool.bat b CrashTest CrashTest-fake.apk 


签名 : java -jar signapk.jar testkey.x509.pem testkey.pk8 CrashTest- 
fake.apk CrashTest-fake-signed.apk. 





需要 注意 的 是 ， 由 于 Windows 系 统 的 兼容 性 问题 ， 有 时 候 会 导致 
apktool.bat 无 法 在 Windows 的 一 些 版 本 上 正常 工作 ， 比 如 Windows 8， 这 
个 时 候 可 以 安装 Cygwin， 然 后 采用 Linux 的 方式 来 进行 打包 即 可 。 除 此 
之 外 ， 部 分 apk 也 可 能 会 打包 失败 ， 以 笔者 的 个 人 经 验 来 说 ，apktool 在 
Linux 上 的 打包 成 功率 要 比 Windows 高 。 


这 里 对 上 面 的 二 次 打包 的 命令 稍 作 解释 ， 解 包 命 令 中 ，d 表 示 解 
包 ，CrashTest.apk 表 示 待 解 包 的 apk，CrashTest 表 示 解 包 后 的 文件 的 存 
储 路 径 ，-{f 表 示 如 果 CrashTest 目 录 已 经 存在 ， 那 么 直接 履 兰 它 。 





打包 命令 中 ，b 表 示 打 包 ，CrashTest 表 示 解 包 后 的 文件 的 存储 路 
径 ，CrashTest-fake.apk 表 示 二 次 打包 后 的 文件 名 。 通 过 apktool 解 包 以 
后 ， 可 以 查看 到 apk 中 的 资源 以 及 smali 文 件 ，smali 文 件 是 dex 文 件 反 编 
译 〈 不 同 于 dex2jar 的 反 编 译 过 程 ) 的 结果 。smali 有 上 自己 的 语法 并 且 可 以 
修改 ， 修 改 后 可 以 被 二 次 打包 为 apk， 通 过 这 种 方式 就 可 以 修改 apk 的 执 
行 逻 辑 ， 显 然 这 让 山寨 应 用 变 得 十 分 危险 。 需 要 注意 的 是 ，apk 经 过 二 
次 打包 后 并 不 能 直接 安装 ， 必 须要 经 过 签名 后 才能 安装 。 








签名 命令 中 ， 采 用 signapk.jar 来 完成 签名 ， 签 名 后 生成 的 apk 就 是 一 
个 山寨 版 的 apk， 因 为 签名 过 程 中 所 采用 的 签名 文件 不 是 官方 的 ， 最 终 
CrashTest-fake-signed.apk 就 是 二 次 打包 形成 的 一 个 山寨 版 的 apk。 对 于 本 
文中 的 例子 来 说 ，CrashTest-fake-signed.apk 安 装 后 其 功能 和 正版 的 
CrashTest.apk 是 没有 区 别 的 。 

















在 实际 开发 中 ， 很 多 产品 都 会 做 签名 校 验 ， 简 单 的 二 次 打包 上 所 得 到 
的 山寨 版 apk 安 六 后 无 法 运行 。 尺 管 如 此 ， 还 是 可 以 通过 修改 smali 的 方 
式 来 绕 过 签名 校 验 ， 这 就 是 为 什么 市 面 上 仍然 有 那么 多 的 山 笃 版 应 用 的 
原因 。 一 般 来 说 山寨 版 应 用 都 具有 一 定 的 危害 性 ， 我 们 要 抵制 山寨 版 应 
用 以 防止 自己 的 财产 遭受 到 损失 。 关 于 smali 的 语法 以 及 如 何 修改 
smali， 这 就 属于 比较 深入 的 话题 了， 本 市 不 再 对 它们 进行 深入 的 介绍 ， 
感 兴趣 的 话 可 以 阅读 逆向 方面 的 专业 书籍 ， 也 可 以 阅读 笔者 之 前 写 的 一 
篇 介绍 应 用 人 破解 的 文章 : http://blog.csdn.net/ 
singwhatiwanna/article/details/18797493。 








第 14 晶 ”JN1 和 NDK 编 程 


Java JNI 的 本 意 是 Java Native Interface (Java 本 地 接口 ) ， 它 是 为 了 
方便 Java ”调用 C、C++ 等 本 地 代码 所 封装 的 一 层 接口 。 我 们 都 知道 ， 
Java 的 优点 是 跨 平 台 ， 但 是 作为 优点 的 同时 ， 其 在 和 本 地 交互 的 时 候 就 
出 现 了 短 板 。Java 的 跨 平 台 特性 导致 其 本 地 交互 的 能 力 不 够 强大 ， 一 些 
和 操作 系统 相关 的 特性 Java 无 法 完成 ， 于 是 Java 提 供 了 JNI 专 门 用 于 和 本 
地 代码 交互 ， 这 样 束 增强 了 Java 语 言 的 本 地 交互 能 力 。 通 过 Java JNI, 
用 户 可 以 调用 用 C、C++ 所 编写 的 本 地 代码 。 


NDK 是 Android 所 提供 的 一 个 工具 集合 ， 通 过 NDK 可 以 在 Android 中 
更 加 方便 地 通过 JNI 来 访问 本 地 代码 ， 比 如 C 或 者 C++。NDK 还 提供 了 交 
叉 编译 器 ， 开 发 人 员 只 需要 简单 地 修改 mk 文件 就 可 以 生成 特定 CPU 平 
台 的 动态 库 。 使 用 NDK 有 如 下 好 处 : 





C1) 提高 代码 的 安全 性 。 由 于 so 库 反 编译 比较 困难 ， 因 此 NDK 提 
高 了 Android 程 序 的 安全 性 。 


(2) 可 以 很 方便 地 使 用 目前 已 有 的 C/C++ 开源 库 。 








(3) 便于 平台 间 的 移植 。 通 过 C/C++ 实现 的 动态 库 可 以 很 方便 地 
在 其 他 平台 上 使 用 。 





(4) 提高 程序 在 某 些 特定 情形 下 的 执行 效率 ， 但 是 并 不 能 明显 提 
升 Android 程 序 的 性 能 。 


由 于 JNI 和 NDK 比 较 适 合 在 Linux 环 境 下 开发 ， 因 此 本 文选 择 Ubuntu 
14.10 (64 位 操作 系统 ) 作为 开发 环境 ， 同 时 选择 AndroidStuio 作 为 
IDE。 人 至 于 Windows 环 境 下 的 NDK 开 发 ， 整 体 流 程 是 类 似 的 ， 有 差别 的 
只 是 和 操作 系统 相关 的 特性 ， 这 里 就 不 再 单独 介绍 了 。 在 Linux 环 境 
中 ，JNI 和 NDK 开 发 所 用 到 的 动态 库 的 格式 是 以 .so 为 后 级 的 文件 ， 下 面 
统一 简称 为 so 库 。 另 外 ， 由 于 JNI 和 NDK 主 要 用 于 底层 和 嵌入 式 开 发 ， 
在 Android 的 应 用 层 开 发 中 使 用 较 少 ， 加 上 它们 本 里 更 加 侧重 于 C 和 
C++ 方面 的 编程 ， 因 此 本 章 只 介绍 JNI 和 NDK 的 基础 知识 ， 其 他 更 加 深 
入 的 知识 点 如 果 读 者 感 兴 趣 的 话 可 以 查看 专门 介绍 JNI 和 NDK 的 书籍 。 





14.1 JNI 的 开发 流程 


JNI 的 开发 流程 有 如 下 几 步 ， 首 先 需要 在 Java 中 声明 native 方 法 ， 接 
着 用 C 或 者 C++ 实现 native 方 法 ， 然 后 就 可 以 编译 运行 了 。 


1. 在 Java 中 声明 native 方 法 


创建 一 个 类 ， 这 里 叫做 JniTestjava， 代 码 如 下 所 示 。 





可 以 看 到 上 面 的 代码 中 ， 声 明了 两 个 native 方 法 : get 和 set(String)， 
这 两 个 就 是 需要 在 JNI 中 实现 的 方法 。 在 JniTest 的 头 部 有 一 个 加 载 动态 


库 的 过 程 ， 其 中 jni-test 是 so 库 的 标识 ，so 库 完整 的 名 称 为 libjni-test.so， 
这 是 加 载 so 库 的 规范 。 


2. 编译 Java 源 文件 得 到 class 文 件 ， 然 后 通过 javah 命 令 导 出 JNI 的 
头 文件 


具体 的 命令 如 下 : 


在 当前 目录 下 ， 会 产生 一 个 com_ryg_JniTesth 的 头 文件 ， 它 是 javah 
命令 自动 生成 的 ， 内 容 如 下 所 示 。 





(JNIEnv *, jobject); 


fe 
* Class: com_ryg_JniTest 
* Method: set 


* Signature: (Ljava/lang/String; )V 
Wee 
JNIEXPORT void JNICALL Java_com_ryg_JniTest_set 
(JNIEnv *, jobject, jstring); 
#ifdef _ cplusplus 
i 
#endif 


#endif 


ET AYRES m F, E ERRA A EP I: 
Java_ 包 名 _ 类 名 方法 名 。 比 如 JniTest 中 的 set 方 法 ， 到 这 里 就 变 成 了 
JNIEXPORT void JNICALL Java_com_ryg_JniTest_set(JNIEnv 
*#,jobjectjstring)， 其 中 com_ryg 是 包 名 ，JniTest 是 类 名 ，jstring 是 代表 的 
是 set 方 法 的 String 类 型 的 参数 。 关 于 Java 和 JNI 的 数据 类 型 之 间 的 对 应 关 
系 会 在 14.3 节 中 进行 介绍 ， 这 里 只 需要 知道 Java 的 String 对 应 于 JNI 的 
jstring 即 可 。JNIEXPORT、JNICALL、JNIEnv 和 jobject 都 是 JNI 标 准 中 所 
定义 的 类 型 或 者 宏 ， 它 们 的 含义 如 下 : 











e JNIEnv*: 表示 一 个 指 问 JNI 环 境 的 指针 ， 可 以 通过 它 来 访问 JNI 提 
供 的 接口 方法 ; 

e jobject: 表示 Java 对 象 中 的 this; 

。JNIEXPORT 和 JNICALL: 它们 是 JNI 中 所 定义 的 宏 ， 可 以 在 jni.h 这 
个 头 文件 中 查找 到 。 








下 面 的 宏 定义 是 必需 的 ， 它 指定 extern "C" 内 部 的 函数 采用 C 语 言 的 
命名 风格 来 编译 。 否 则 当 JNI 采 用 C++ 来 实现 时 ， 由 于 C 和 C++ 编译 过 程 
中 对 函数 的 命名 风格 不 同 ， 这 将 导致 JNI 在 链接 时 无 法 根据 函数 名 查找 
到 有 具体 的 函数 ， 那 么 JNI 调 用 就 无 法 完成 。 更 多 的 细节 实际 上 是 有 关 C 和 
C++ 编译 时 的 一 些 问题 ， 这 里 就 不 再 展开 了 。 





#ifdef _ cplusplus 
extern "C" { 


#endif 
3. 实现 JNI 方 法 


JNI 方 法 是 指 Java 中 声明 的 native 方 法 ， 这 里 可 以 选择 用 C++ 或 者 C 来 
实现 ， 它 们 的 实现 过 程 是 类 似 的 ， 只 有 少量 的 区 别 ， 下 面 分 别 用 C++ 和 
C 来 实现 JNT 方 法 。 首 先 ， 在 工程 的 主 目录 下 创建 一 个 子 目 录 ， 名 称 随 
意 ， 这 里 选择 jni 作 为 子 目 录 的 名 称 ， 然 后 将 之 前 通过 javah 生 成 的 头 文 
件 com_ryg_JniTest.h 复 制 到 jni 目 录 下 ， 接 着 创建 test.cpp 和 和 test.c 两 个 文 
件 ， 它 们 的 实现 如 下 所 示 。 











// test.cpp 
#include "com_ryg_JniTest.h" 
#include <stdio.h> 
JNIEXPORT jstring JNICALL Java_com_ryg_JniTest_get(JNIEnv *en 
thiz) { 
printf("invoke get in c++\n"); 
return env->NewStringUTF("Hello from JNI !"); 
J 
JNIEXPORT void JNICALL Java_com_ryg_JniTest_set(JNIEnv *env,j 


可 以 发 现 ，test.cpp 和 test.c 的 实现 很 类 似 ， 但 是 它们 对 env 的 操作 方 
式 有 所 不 同 ， 因 此 用 C++ 和 C 来 实现 同一 个 JNI 方 法 ， 它 们 的 区 别 主要 集 
中 在 对 env 的 操作 上 上， 其 他 都 是 类 似 的 ， 如 下 所 示 。 





C: (*env)->NewStringUTF(env, "Hello from JNI !") 
4. 编译 so 库 并 在 Java 中 调用 


so 库 的 编译 这 里 采用 gcc， 切 换 到 jni 目 录 中 ， 对 于 test.cpp 和 test.c 来 
说 ， 它 们 的 编译 指令 如 下 所 示 。 


C++: gcc -shared -I /usr/lib/jvm/java-7-openjdk-amd64/include 


C: gcc -shared -I /usr/lib/jvm/java-7-openjdk-amd64/include 


上 面 的 编译 命令 中 ，/usr/lib/jvm/java-7-openjdk-amd64 是 本 地 的 jdk 

的 安装 路 人 符 ， 在 其 他 环境 编译 时 将 其 指 同 本 机 的 jdk 足 径 即 可 。 而 libjni- 
test.so 则 是 生成 的 so 库 的 名 字 ， 在 Java 中 可 以 通过 如 下 方式 加 载 : 
System.loadLibrary("jni-test")， 其 中 so 库 名 字 中 的 ib” 和 “.so” 是 不 需要 明 
确 指出 的 。so 库 编译 完成 后 ， 束 可 以 在 Java 程 序 中 调用 so 库 了 ， 这 里 通 
过 Java 指 令 来 执行 Java 程 序 ， 切 换 到 主 目录 ， 执 行 如 下 指令 : java = 
Djava.library.path=jni com.ryg.JniTest， 其 中 -Djava.library.path=jni 指 明了 
so 库 的 路 径 。 














首先 ， 采 用 C++ 产生 so 库 ， 程 序 运 行 后 产生 的 日 志 如 下 所 示 。 


invoke get in C++ 
Hello from JNI ! 
invoke set from C++ 


hello world 








然后 ， 采 用 C 产 生 so 库 ， 程 序 运 行 后 产生 的 日 志 如 下 所 示 。 


invoke get from C 


Hello from JNI ! 


通过 上 面 的 日 志 可 以 发 现 ， 在 Java 中 成 功 地 调用 了 C/C++ 的 代码 ， 
这 就 是 JNI 典 型 的 工作 流程 。 


14.22 NDK 的 开发 流程 


NDK 的 开发 是 基于 JNI 的 ， 其 主要 由 如 下 几 个 步骤 。 
1. 下 载 并 配置 NDK 


首先 要 从 Android 官 网 上 下 载 NDK， 下 载 地 址 为 
https://developer.android.com/ndk/downloads/index.html, 5% PKH 
NDK 的 版 本 是 android-ndk-r10d。 下 载 完 成 以 后 ， 将 NDK 解 压 到 一 个 目 
录 ， 然 后 为 NDK 配 置 环 境 变 量 ， 步 骤 如 下 上 所 示 。 





首先 打开 当前 用 户 的 环境 变量 配置 文件 : 


vim ~/.bashrc 


然后 在 文件 后 面 添加 如 下 信息 : export © PATH=~/Android/android- 
ndk-r10d:$PATH， 其 中 ~/Android/android-ndk-r10d 是 本 地 的 NDK 的 存放 
路 径 。 


添加 完毕 后 ， 执 行 source ”~/.bashrc 来 立刻 刷新 刚刚 设置 的 环境 变 
量 。 设 置 完 环 境 变 量 后 ，ndk-build 命 令 就 可 以 使 用 了 ， 通 过 ndk-build 命 
令 束 可 以 编译 产生 so 库 。 





2. 创建 一 个 Android 项 目 ， 并 声明 所 需 的 native 方 法 


package com.ryg.JniTestApp; 
import android.support.v7.app.ActionBarActivity; 


import android.os.Bundle; 


3. 实现 Android 项 目 中 所 声明 的 native 方 法 


在 外 部 创建 一 个 名 为 jni 的 目录 ， 然 后 在 jni 目 录 下 创建 3 个 文件 : 
test.cpp、Android.mk 和 Application.mk， 它 们 的 实现 如 下 所 示 。 








#distributed under the License is distributed on an "AS IS" 
#WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,either express 
#See the License for the specific language governing permiss 
#limitations under the License. 

# 

LOCAL_PATH := $(call my-dir) 

include $(CLEAR_VARS) 

LOCAL_MODULE := jni-test 

LOCAL_SRC_FILES := test.cpp 
include $(BUILD_SHARED_LIBRARY ) 
// Application.mk 


APP_ABI := armeabi 


这 里 对 Android.mk 和 Application.mk 做 一 下 简单 的 介绍 。 在 
Android.mk 中 ，LOCAL_ MODULE 表示 模块 的 名 称 ， 
LOCAL_SRC_FILES 表 示 需 要 参与 编译 的 源 文件 。Application.mk 中 常用 
的 配置 项 是 APP_ABI， 它 表示 CPU 的 架构 平台 的 类 型 ， 目 前 市 面 上 常见 
的 架构 平台 有 armeabi、x86 和 mips， 其 中 在 移动 设备 中 占据 主要 地 位 的 
是 armeabi， 这 也 是 大 部 分 apk 中 只 包含 armeabi 类 型 的 so 库 的 原因 。 默 认 
情况 下 NDK 会 编译 产生 各 个 CPU 平台 的 so 库 ， 通 过 APP_ABI 选 项 即 可 指 
定 so 库 的 CPU 平台 的 类 型 ， 比 如 armeabi， 这 样 NDK 就 只 会 编译 armeabi 
平台 下 的 so 库 了 ， 而 ad 则 表示 编译 所 有 CPU 平台 的 so 库 。 

















4. 切换 到 jni 目 录 的 父 目 录 ， 然 后 通过 ndk-build 命 令 编 译 产 生 so 库 


这 个 时 候 NDK 会 创建 一 个 和 jni 目 录 平 级 的 目录 libs，libs 下 面 存放 的 
就 是 so 库 的 目录 ， 如 图 14-1 所 示 。 需 要 注意 的 是 ，ndk-build 命 令 会 默认 
旨 定 jni 目 录 为 本 地 源码 的 目录 ， 如 果 源 人 码 存放 的 目录 名 不 是 jni， 那 么 











ndk-build 则 无 法 成 功 编译 。 
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图 14-1 通过 NDK 编 译 产 生 的 so 库 


然后 在 app/srcmain 中 创建 一 个 名 为 jniLibs 的 目录 ， 将 生成 的 so 库 复 
制 到 jniLibs 目 录 中 ， 然 后 通过 AndroidSstudio 编 译 运行 即 可 ， 运 行 效果 如 
图 14-2 所 示 。 这 说 明 从 Android 中 调用 so 库 中 的 方法 已 经 成 功 了 。 








JniTestApp 





Hello from JNI in libjri-test.so ! 


图 14-2 Android 中 调用 so 库 中 的 方法 示例 


在 上 面 的 步骤 中 ， 需 要 将 NDK 编 译 的 so 库 放 置 到 jniLibs 目 录 下 ， 这 
个 是 AndroidStudio 所 识别 的 默认 目录 ， 如 果 想 使 用 其 他 目录 ， 可 以 按照 
如 下 方式 修改 App 的 build.gradle 文 件 ， 其 中 jniLibs.srcDir 选 项 指定 了 新 的 
存放 so 库 的 目录 。 








除了 手动 使 用 ndk-build 命 令 创 建 so 库 ， 还 可 以 通过 AndroidStudio 来 
自动 编译 产生 so 库 ， 这 个 操作 过 程 要 稍微 复杂 一 些 。 为 了 能 够 让 
AndroidStudio 自 动 编译 JNI 代 码 ， 首 先 需要 在 App 的 build.gradle 的 
defaultConfig 区 域内 添加 NDK 选 项 ， 其 中 moduleName 指 定 了 模块 的 名 
称 ， 这 个 名 称 指定 了 打包 后 的 so 库 的 文件 名 ， 如 下 所 示 。 





接着 需要 将 JNI 的 代码 放 在 app/src/main/jni 目 录 下 ， 注 意 存放 JNI 代 


码 的 目录 名 必须 为 jni， 如 果 不 想 采用 jni 这 个 名 称 ， 可 以 通过 如 下 方式 来 
指定 JNI 的 代码 路 径 ， 其 中 jni.srcDirs 指 定 了 JNI 代 码 的 路 径 : 





经 过 了 上 面 的 步骤 ，AndroidStudio 就 可 以 自动 编译 JNI 代 码 了 ， 但 
是 这 个 时 候 AndroidSstudio 会 把 所 有 CPU 平台 的 so 库 都 打包 到 apk 中 ， 一 
般 来 说 实际 开发 中 只 需要 打包 armeabi 平 台 的 so 库 即 可 。 要 解决 这 个 问题 
也 很 简单 ， 按 照 如 下 方式 修改 build.gradle 的 配置 ， 然 后 在 Build Variants 
面板 中 选择 armDebug 选 项 进行 编辑 就 可 以 了 。 





如 图 14-3 所 示 ， 可 以 看 到 apk 中 就 只 有 armeabi 平 台 的 so 库 了 。 


app-arm-debug.apk 
R Bas 
Ç sit 个 会 位 置 (L) : D /lib/armeabi/ 


Big + al =i 己 修 改 
libjnitest.so Y 共享 库 2015 年 5 月 29 日 15;35 





1 个 对 象 (9.4 KB) 


图 14-3 AndroidStudio 打 包 后 的 apk 


14.3 JNI 的 数据 次 型 和 次 型 签名 


JNI 的 数据 类 型 包含 两 种 : 基本 类 型 和 引用 类 型 。 基 本 类 型 主要 有 


jboolean 、jchar、jint 等 ， 它 们 和 Java 中 的 数据 类 型 的 对 应 关系 如 表 14-1 
BAAR o 


表 14-1 JNI 基 本 数据 类 型 的 对 应 关系 


JNI 类 型 Java 类 型 描 R 





jboolean boolean 无 符号 8 位 整 型 





jbyte byte 有 符号 8 位 整 型 





jchar char 无 符号 16 位 整 型 





jshort short 


有 符号 16 位 整 型 





jint int 32 位 整 型 





jlong long 64 位 整 型 





jfloat float 


jdouble 





double 
void 














void 


JNI 中 的 引用 类 型 主要 有 类 、 对 象 和 数组 ， 


它们 和 Java 中 的 引用 类 
型 的 对 应 关系 如 表 14-2 所 示 。 


表 14-2 JNI 引 用 类 型 的 对 应 关系 


JNI 类 型 Java 类 型 描 R 





jobject Object Object 类 型 





jclass Class Class 类 型 





jstring String 字符 串 





jobjectArray Object[] 对 象 数组 





jbooleanArray boolean[] boolean 数组 





jbyteArray byte[] byte 数组 





jeharArray char[] char 数组 





jshortArray short{] short 数组 





jintArray int[] int 24 





jlongArray long[] long 数组 





jfloatArray float[] float 数组 





jdoubleArray double[] double 数组 











jthrowable Throwable Throwable 





JNI 的 类 型 签名 标识 了 一 个 特定 的 Java 类 型 ， 这 个 类 型 既 可 以 是 类 
和 方法 ， 也 可 以 是 数据 类 型 。 


类 的 签名 比较 简单 ， 它 采用 “+ 包 名 + 类 名 +;” 的 形式 ， 只 需要 将 其 
中 的 .替换 为 / 即 可 。 比 如 java.lang.String， 它 的 签名 为 Ljava/lang/String;， 
注意 末尾 的 ;也 是 签名 的 一 部 分 。 





基本 数据 类 型 的 签名 采用 一 系列 大 写字 母 来 表示 ， 如 表 14-3 所 示 。 
表 14-3 基本 数据 类 型 的 签名 


Java 类 型 签 Java 类 型 


boolean long 








byte float 


double 





void 














从 表 14-3 可 以 看 出 ， 基 本 数据 类 型 的 签名 是 有 规律 的 ， 一 般 为 首 字 
母 的 大 写 ， 但 是 boolean 除 外 ， 因 为 B 已 经 被 byte 占 用 了 ， 而 long 的 签名 
之 所 以 不 是 L， 那 是 因为 表示 的 是 类 的 签名 。 





对 象 和 数组 的 签名 稍微 复杂 一 些 。 对 于 对 象 来 说 ， 它 的 签名 就 是 对 
象 所 属 的 类 的 签名 ， 比 如 String 对 象 ， 它 的 签名 为 Ljava/lang/String;。 对 
于 数组 来 说 ， 它 的 签名 为 [+ 类 型 签名 ， 比 如 int 数 组 ， 其 类 型 为 int， 而 int 
的 签名 为 1， 所 以 int 数 组 的 签名 就 是 [II， 同 理 就 可 以 得 出 如 下 的 签名 对 应 
RR: 





char[ ] [Cc 
float[] [F 
double[] [D 
long[] [J 
String[ ] [Ljava/lang/String; 
Object[ ] [Ljava/lang/Object; 


对 于 多 维 数组 来 说 ， 它 的 签名 为 n 个 [+ 类 型 签名 ， 其 中 n 表 示 数 组 的 
维度 ， 比 如 ，int[][D 的 签名 为 [[I， 其 他 情况 可 以 依 此 类 推 。 


方法 的 签名 为 (参数 类 型 签名 ) + 返回 值 类 型 签名 ， 这 有 点 不 好 理 
解 。 举 个 例子 ， 如 下 方法 : boolean fun1(int adouble b,int[] c)， 根 据 签名 
的 规则 可 以 知道 ， 它 的 参数 类 型 的 签名 连 在 一 起 是 IDII， 返 回 值 类 型 的 
签名 为 2， 所 以 整个 方法 的 签名 就 是 IDIDZ。 再 举 个 例子 ， 下 面 的 方 
法 : boolean funl(int a,String b,int[] cc)， 它 的 签名 是 (ILjava/lang/String; 
[DZ。 为 了 能 够 更 好 地 理解 方法 的 签名 格式 ， 下 面 再 给 出 两 个 示例 : 


int fun1() 签名 为 ()I 
void funi(int i) 签名 为 (I)V 


14.4 JNIi 调 用 Java 方 法 的 流程 


JNI 调 用 Java 方 法 的 流程 是 先 通 过 类 名 找到 类 ， 然 后 再 根据 方法 名 
找到 方法 的 d， 最 后 束 可 以 调用 这 个 方法 了 。 如 果 是 调用 Java 中 的 非 静 
态 方 法 ， 那 么 需要 构造 出 类 的 对 象 后 才能 调用 它 。 下 面 的 例子 演示 了 如 
何在 JNI 中 调用 Java 的 静态 方法 ， 至 于 调用 非 静 态 方法 只 是 多 了 一 步 构 
造 对 象 的 过 程 ， 这 里 就 不 再 介绍 了 。 








首先 需要 在 Java 中 定义 一 个 静态 方法 供 JNI 调 用 ， 如 下 所 示 。 


public static void methodCalledByJni(String msgFromJni) { 
Log.d(TAG, "methodCalledByJni,msg: " + msgFromJni); 


然后 在 JNI 中 调用 上 面 定 义 的 静态 方法 : 


void callJavaMethod(JNIEnv “env, jobject thiz) { 
jclass clazz = env->FindClass("com/ryg/JniTestApp/MainAc 
if (clazz == NULL) { 
printf("find class MainActivity error!"); 
return; 
} 
jmethodID id = env->GetStaticMethodID(clazz,"methodCalle 
"(Ljava/lang/String; )V"); 
if (id == NULL) { 
printf("find method methodCalledByJni error!"); 


} 


jstring msg = env->NewStringUTF("msg send by callJavaMet 
test.cpp."); 


env->CallStaticVoidMethod(clazz,id,msg); 





从 callJavaMethod 的 实现 可 以 看 出 ， 程 序 首先 根据 类 名 
com/ryg/JniTestApp/MainActivity 找 到 类 ， 然 后 再 根据 方法 名 
methodCalledByJni 找 到 方法 ， 其 中 (Ljava/lang/String;)V 是 
methodCalledByJni 方 法 的 签名 ， 接 着 再 通过 JNIEnv 对 象 的 
CallStaticVoidMethod 方 法 来 完成 最 终 的 调用 过 程 。 








最 后 在 Java_com_ryg_JniTestApp_MainActivity_get 方 法 中 调用 
callJavaMethod 方 法 ， 如 下 所 示 。 


jstring Java_com_ryg_JniTestApp_MainActivity_get(JNIEnv *env, 
printf("invoke get in c++\n"); 
callJavaMethod(env, thiz); 


return env->NewStringUTF("Hello from JNI in libjni-test. 


由 于 MainActivity 会 调用 JNI 中 的 
Java_com ryg_JniTestApp_MainActivity_get 方 法 ， 
Java_com_ryg_JniTestApp_MainActivity_get 方 法 又 会 调用 callJavaMethod 
方法 ， 而 callJavaMethod 方 法 又 会 反 过 来 调用 MainActivity 的 
methodCalledByJni 方 法 ， 这 样 一 来 就 完成 了 一 次 从 Java 调 用 JNI 然 后 再 从 
JNI 中 调用 Java 方 法 的 过 程 。 安 装运 行程 序 ， 可 以 看 到 如 下 日 志 ， 这 说 
明 程序 已 经 成 功 地 从 JNI 中 调用 了 Java 中 的 methodCalledByJni 方 法 。 








D/MainActivity: methodCalledByJni,msg: msg send by callJavaMe 





我 们 可 以 发 现 ，JNI 调 用 Java 的 过 程 和 Java 中 方法 的 定义 有 很 大 关 
联 ， 针 对 不 同类 型 的 Java 方 法 ，JNIEnv 提 供 了 不 同 的 接口 去 调用 ， 本 章 
作为 一 个 JNI 的 入 门 章节 就 不 再 对 它们 一 一 进行 介绍 了 ， 毕 竟 大 部 分 应 
用 层 的 开发 人 员 并 不 需要 那么 深入 地 了 解 JNI， 如 果 读 者 感 兴 趣 可 以 自 
行 阅 读 相 关 的 JNI 专 业 书 籍 。 


$15% Android 性 能 优化 





本 章 是 本 书 的 最 后 一 革 ， 所 介绍 的 主题 是 Android 的 性 能 优化 方法 
和 程序 设计 的 一 些 思想 。 通 过 本 章 的 内 容 ， 读 者 可 以 掌握 常见 的 性 能 优 
化 方法 ， 这 将 有 助 于 提高 Android 程 序 的 性 能 ; 男 一 方面 ， 本 章 还 讲解 
了 Android 程 序 设计 的 一 些 思想 ， 这 将 有 助 于 提高 程序 的 可 维护 性 和 可 
扩展 性 。 另 外 ，2015 年 Google 在 YouTube 上 发 布 了 关于 Android 性 能 优化 
典范 的 专题 ， 通 过 一 系列 短视 频 来 帮助 开发 者 创建 更 快 更 优秀 的 
Android 应 用 ， 课 程 专题 不 仅仅 介绍 了 Android 系 统 中 有 关 性 能 问题 的 底 
层 工作 原理 ， 同 时 也 介绍 了 如 何 通过 工具 来 找 出 性 能 问题 以 及 提升 性 能 
的 建议 ， 地 址 是 : 





https://www. youtube.com/playlist? 
list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE. 





Android 设 备 作为 一 种 移动 设备 ， 不 管 是 内 存 还 是 CPU 的 性 能 都 受 
到 了 一 定 的 限制 ， 无 法 做 到 像 PC 设备 那样 具有 超大 的 内 存 和 高 性 能 的 
CPU。 鉴 于 这 一 点 ， 这 也 意味 着 Android 程 序 不 可 能 无 限制 地 使 用 内 存 
和 CPU 资源 ， 过 多 地 使 用 内 存 会 导致 程序 内 存 溢出 ， 即 OOM。 而 过 多 
地 使 用 CPU 资源 ， 一 般 是 指 做 大 量 的 耗 时 任务 ， 会 导致 手机 变 得 卡 顿 其 
至 出 现 程序 无 法 响应 的 情况 ， 即 ANR。 由 此 来 看 ，Android 程 序 的 性 能 
问题 就 变 得 异常 突出 了 ， 这 对 开发 人 员 也 提出 了 更 高 的 要 求 。 为 了 提高 
应 用 程序 的 性 能 ， 本 章 第 一 节 介 绍 了 一 些 有 效 的 性 能 优化 方法 ， 主 要 内 
容 包 括 布局 优化 、 绘 制 优化 、 内 存 泄 露 优化 、 响 应 速度 优化 、ListView 

















优化 、Bitmap 优 化 、 线 程 优化 以 及 一 些 性 能 优化 建议 ， 同 时 在 介绍 啊 应 
速度 优化 的 同时 还 介绍 了 ANR 日 志 的 分 析 方 法 。 





性 能 优化 中 一 个 很 重要 的 问题 就 是 内 存 泄露 ， 内 存 泄露 并 不 会 导致 
程序 功能 异常 ， 但 是 它 会 导致 Android 程 序 的 内 存 占用 过 大 ， 这 将 提高 
内 存 溢出 的 发 生 几 率 。 如 何 避 免 写 出 内 存 泄 露 的 代码 ， 这 和 开发 人 员 的 
水 平和 意识 有 很 大 关系 ， 甚 至 很 多 情况 下 内 存 泄 露 的 原因 是 很 难 直 接 发 
现 的 ， 这 个 时 候 就 需要 借助 一 些 内 存 泄露 分 析 工 具 ， 在 本 章 的 第 二 市 将 
介绍 内 存 泄 露 分 析 工 具 MAT 的 使 用 ， 通 过 MAT 就 可 以 发 现 一 些 开 发 过 
程 中 难以 发 现 的 内 存 泄露 问题 。 


























在 做 程序 设计 时 ， 除 了 要 完成 功能 开发 、 提 高 程序 的 性 能 以 外 ， 还 
有 一 个 问题 也 是 不 容 忽 视 的 ， 那 就 是 代码 的 可 维护 性 和 可 扩展 性 。 如 果 
一 个 程序 的 可 维护 性 和 可 扩展 性 很 差 ， 那 就 意味 着 后 续 的 代码 维护 代价 
是 相当 高 的 ， 比 如 需要 对 一 个 功能 做 一 些 调整 ， 这 可 能 会 出 现 牵 一 发 而 
动 全 身 的 局 面 。 另 外 添加 新 功能 时 也 党 得 无 从 下 手 ， 整 个 代码 看 起 来 可 
读 性 很 差 ， 这 的 确 是 一 份 很 糟 料 的 代码 。 关 于 代码 的 可 维护 性 和 可 扩展 
性 ， 看 起 来 是 一 个 很 抽象 的 问题 ， 其 实 它 并 不 抽象 ， 它 是 可 以 通过 一 些 
合理 的 设计 原则 去 完成 的 ， 比 如 良好 的 代码 风格 、 清 晰 的 代码 层级 、 代 
码 的 可 扩展 性 和 合理 的 设计 模式 ， 在 本 半 的 第 三 市 对 这 些 设计 原则 做 了 
介绍 ， 这 将 在 一 定 程度 上 提高 程序 的 可 维护 性 和 可 扩展 性 。 

















15.1 Android 的 性 能 优化 方法 


本 节 介 绍 了 一 些 有 效 的 性 能 优化 方法 ， 主 要 内 容 包括 布局 优化 、 绘 
制 优化 、 内 存 泄露 优化 、 啊 应 速度 优化 、ListView 优 化 、Bitmap 优 化 、 
线程 优化 以 及 一 些 性 能 优化 建议 ， 在 介绍 响应 速度 优化 的 同时 还 介绍 了 
ANR 日 志 的 分 析 方 法 。 


15.1.1 布局 优化 








布局 优化 的 思想 很 简单 ， 就 是 尽量 减少 布局 文件 的 层级 ， 这 个 道理 
征 很 浅显 的 ， 布 局 中 的 层级 少 了 ， 这 吏 意 味 痢 Android 绘 制 时 的 工作 量 
少 了 ， 那 么 程序 的 性 能 目 然 台 局 了 。 


如 何 进 行 布 局 优化 呢 ? 首先 删除 布局 中 无 用 的 控件 和 层级 ， 其 次 有 
选择 地 使 用 性 能 较 低 的 ViewGroup， 比 如 RelativeLayout。 如 果 布 局 中 既 
可 以 使 用 LinearLayout 也 可 以 使 用 RelativeLayout， 那 么 就 及 用 
LinearLayout， 这 是 因为 RelativeLayout 的 功能 比较 复杂 ， 它 的 布局 过 程 
需要 花费 更 多 的 CPU 时 间 。FrameLayout 和 LinearLayout 一 样 都 是 一 种 简 
单 高 效 的 ViewGroup， 因 此 可 以 考虑 使 用 它们 ， 但 是 很 多 时 候 单纯 通过 
一 个 LinearLayout 或 者 FrameLayout 无 法 实现 产品 效果 ， 需 要 通过 般 套 的 
方式 来 完成 。 这 种 情况 下 还 是 建议 采用 RelativeLayout， 因 为 ViewGroup 
的 藤 套 就 相当 于 增加 了 布局 的 层级 ， 同 样 会 降低 程序 的 性 能 。 





布局 优化 的 另外 一 种 手段 是 采用 <include> 标 签 、<merge> 标 签 和 
ViewStub。<include> 标 签 主 要 用 于 布局 重用 ，<merge> 标 签 一 般 和 








<include> 配 合 使 用 ， 它 可 以 降低 减少 布局 的 层级 ， 而 ViewStub 则 提供 了 
按 需 加 载 的 功能 ， 当 需要 时 才 会 将 ViewStub 中 的 布局 加 载 到 内 存 ， 这 提 
高 了 程序 的 初始 化 效率 ， 下 面 分 别 介绍 它们 的 使 用 方法 。 


<include> 标 签 


<include> 标 签 可 以 将 一 个 指定 的 布局 文件 加 载 到 当前 的 布局 文件 
HH, OR AT. 


<LinearLayout xmlns:android="http://schemas.android.com/apk/r 
android: orientation="vertical" 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android: background="@color/app_bg" 


android: gravity="center_horizontal"> 


<include layout="@layout/titlebar"/> 


<TextView android: layout_width="match_parent" 
android: Layout_height="Wwrap_content" 
android: text="@string/text" 


android: padding="5dp" /> 


</LinearLayout> 


上 面 的 代码 中 ，@layouttitlebar 指 定 了 另外 一 个 布局 文件 ， 通 过 这 
种 方式 束 不 用 把 titlebar 这 个 布局 文件 的 内 容 再 重复 写 一 名 了 ， 这 就 是 
<include> 的 好 处 。<include> 标 签 只 支持 以 android:layout_ 开头 的 属性 ， 


比如 android:layout_width、android:layout_height， 其 他 属性 是 不 支持 
的 ， 比 如 android:background。 当 然 ，android:id 这 个 属性 是 个 特例 ， 如 果 
<include> 指 定 了 这 个 id 属性 ， 同 时 被 包含 的 布局 文件 的 根 元 素 也 指定 了 
id 属性 ， 那 么 以 <include> 指 定 的 id 属性 为 准 。 需 要 注意 的 是 ， 如 果 
<include> 标 签 指定 了 android:layout_* 这 种 属性 ， 那 么 要 求 
android:layout_width 和 android:layout_height 必 须 存在 ， 人 否则 其 他 
android:layout_* 形 式 的 属性 无 法 生效 ， 下 面 是 一 个 指定 了 
android:layout_* 属 性 的 示例 。 

<include android:id="@+id/new_ title" 

android: Layout_width="match_parent" 


android: Layout_height="match_parent" 


layout="@layout/title"/> 


<merge> 标 签 





<merge> 标 签 一 般 和 <include> 标 签 一 起 使 用 从 而 减少 布局 的 层级 。 
在 上 面 的 示例 中 ， 由 于 当前 布局 是 一 个 坚 直 方向 的 LinearLayout， 这 个 
时 候 如 果 被 包含 的 布局 文件 中 也 采用 了 竖 直 方向 的 LinearLayout， 那 么 
显然 被 包含 的 布局 文件 中 的 LinearLayout 是 多 余 的 ， 通 过 <merge> 标 签 就 
可 以 去 掉 多 余 的 那 一 层 LinearLayout， 如 下 所 示 。 





<merge xmlns:android="http://schemas.android.com/apk/res/andr 
<Button 
android: Layout_width="wrap_content" 
android: Layout_height="wrap_content" 
android: text="@string/one"/> 


<Button 


android: Layout_width="wrap_content" 
android: Layout_height="wrap_content" 
android: text="@string/two"/> 


</merge> 


ViewStub 





ViewStub 继 承 了 View， 它 非常 轻 量 级 且 宽 /高 都 是 0， 因 此 它 本 里 不 
参与 任何 的 布局 和 绘制 过 程 。ViewStub 的 意义 在 于 按 需 加 载 所 需 的 布局 
文件 ， 在 实际 开发 中 ， 有 很 多 布局 文件 在 正常 情况 下 不 会 显示 ， 比 如 网 
络 异 常 时 的 界面 ， 这 个 时 候 束 没有 必要 在 整个 界面 初始 化 的 时 候 将 其 加 
载 进来 ， 通 过 ViewStub 就 可 以 做 到 在 使 用 的 时 候 再 加 载 ， 提 高 了 程序 初 
始 化 时 的 性 能 。 下 面 是 一 个 ViewStub 的 示例 : 

















<ViewStub 
android: id="@+id/stub_import" 
android: inflatedId="@+id/panel_import" 
android: Layout="@layout/layout_network_error" 
android: Layout_width="match_parent" 
android: Layout_height="wrap_content" 


android: Layout_gravity="bottom" /> 


其 中 stub_import 是 ViewStub 的 id， 而 panel_import 是 
layout/layout_network_error 这 个 布局 的 根 元 素 的 d。 如 何 做 到 按 需 加 载 
呢 ? 在 需要 加 载 ViewStub 中 的 布局 时 ， 可 以 按照 如 下 两 种 方式 进行 : 





((ViewStub) findViewById(R.id.stub_import)).setVisibility(Vie 


或 者 


View importPanel = ((ViewStub) findViewById(R.id.stub_import) 


当 ViewStub 通 过 setVisibility 或 者 inflate 方 法 加 载 后 ，ViewStub 束 会 
被 它 内 部 的 布局 蔡 换 抒 ， 这 个 时 候 ViewStub 苞 不 再 是 整个 布局 结构 中 的 
一 部 分 了 。 另 外 ， 目 前 ViewStub 还 不 文 持 <merge> 标 签 。 


15.1.2 ”绘制 优化 


绘制 优化 是 指 View 的 onDraw 方 法 要 避免 执行 大 量 的 操作 ， 这 主要 
体现 在 两 个 方面 。 





首先 ，onDraw 中 不 要 创建 新 的 局 部 对 象 ， 这 是 因为 onDraw 方 法 可 
能 会 被 频繁 调用 ， 这 样 就 会 在 一 瞬间 产生 大 量 的 临时 对 象 ， 这 不 仅 占 用 
了 过 多 的 内 存 而 且 还 会 导致 系统 更 加 频繁 gc， 降 低 了 程序 的 执行 效率 。 





另外 一 方面 ，onDraw 方 法 中 不 要 做 耗 时 的 任务 ， 也 不 能 执行 成 干 
上 万 次 的 循环 操作 ， 尽 管 每 次 循环 都 很 轻 量 级 ， 但 是 大 量 的 循环 仍然 十 
分 抢占 CPU 的 时 间 片 ， 这 会 造成 View 的 绘制 过 程 不 流畅 。 按 照 Google 官 
方 给 出 的 性 能 优化 典范 中 的 标准 ，View 的 绘制 帧 率 保证 60fps 是 最 佳 
的 ， 这 就 要 求 每 帧 的 绘制 时 间 不 超过 16ms (16ms = 1000/60) ， 虽 然 程 
序 很 难保 证 16ms 这 个 时 间 ， 但 是 尽量 降低 onDraw 方 法 的 复杂 度 总 是 切 
实 有 效 的 。 


15.1.3 ”内存 泄露 优化 


内 存 汇 露 在 开发 过 程 中 是 一 个 需要 重视 的 问题 ,但 是 由 于 内 存 泄露 














问题 对 开发 人 员 的 经 验 和 开发 意识 有 较 高 的 要 求 ， 因 此 这 也 是 开发 人 员 
最 容易 犯 的 错误 之 一 。 内 存 泄露 的 优化 分 为 两 个 方面 ， 一 方面 是 在 开发 
过 程 中 避免 写 出 有 内 存 泄露 的 代码 ， 另 一 方面 是 通过 一 些 分 析 工 具 比 如 
MAT 来 找 出 潜在 的 内 存 泄露 继而 解决 。 本 节 主 要 介绍 一 些 常见 的 内 存 
泄露 的 例子 ， 通 过 这 些 例子 读者 可 以 很 好 地 理解 内 存 泄露 的 发 生 场 景 并 
只 累 规 避 内 存 泄 露 的 经 验 。 关 于 如 何 通 过 工具 分 析 内 存 泄露 将 在 15.2 节 
中 专门 介绍 。 








场景 1: 静态 变量 导致 的 内 存 泄露 








下 面 这 种 情形 是 一 种 最 简单 的 内 存 泄露 ， 相 信 读 者 都 不 会 这 么 干 ， 
下 面 的 代码 将 导致 Activity 无 法 正常 销毁 ， 因 此 静态 变量 SContext 引 用 了 


i 一 大 


Kio 


public class MainActivity extends Activity { 
private static final String TAG = "MainActivity"; 
private static Context sContext; 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_main); 


sContext = this; 


} 


上 面 的 代码 也 可 以 改造 一 下 ， 如 下 所 示 。sView 是 一 个 静态 变量 ， 
它 内 部 持 有 了 当前 Activity， 所 以 Activity 仍 然 无 法 释放 ， 估 计 读 者 也 都 
明日 。 


public class MainActivity extends Activity { 
private static final String TAG = "MainActivity"; 
private static View sView; 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_main); 


sView = new View(this); 


场景 2: 单 例 模式 导致 的 内 存 泄露 


静态 变量 导致 的 内 存 泄露 都 太 过 于 明显 ， 相 信 读 者 都 不 会 犯 这 种 错 
误 ， 而 单 例 模式 所 带 来 的 内 存 泄露 是 我 们 容易 忽视 的 ， 如 下 所 示 。 首 先 
提供 一 个 单 例 模式 的 TestManager，TestManager 可 以 接收 外 部 的 注册 并 
将 外 部 的 监听 器 存储 起 来 。 


public class TestManager { 
private List<OnDataArrivedListener> mOnDataArrivedListen 
ArrayList<OnDataArrivedListener>(); 
private static class SingletonHolder { 
public static final TestManager INSTANCE = new TestM 
k 
private TestManager() { 
J 
public static TestManager getInstance() { 


return SingletonHolder .INSTANCE; 


} 
public synchronized void registerListener (OnDataArrivedL 
listener) { 

if (!mOnDataArrivedListeners.contains(listener)) { 


mOnDataArrivedListeners.add(listener ); 


} 
public synchronized void unregisterListener(OnDataArrive 
listener) { 
mOnDataArrivedListeners.remove(listener); 
} 
public interface OnDataArrivedListener { 


public void onDataArrived(Object data); 


接着 再 让 Activity 实 现 OnDataArrivedListener 接 口 并 疝 TestManager 注 
册 监 听 ， 如 下 所 示 。 下 面 的 代码 由 于 缺少 解 注 册 的 操作 所 以 会 引起 内 存 
泄露 ， 泄 露 的 原因 是 Activity 的 对 象 被 单 例 模式 的 TestManager 所 持 有 ， 
而 单 例 模式 的 特点 是 其 生命 周期 和 Application 保 持 一 致 ， 因 此 Activity 对 
象 无 法 被 及 时 释放 。 





protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_main); 


TestManager.getInstance().registerListener(this); 


场景 3: 属性 动画 导致 的 内 存 泄露 


从 Android 3.0 开 始 ，Google 提 供 了 属性 动画 ， 属 性 动画 中 有 一 类 无 
限 循环 的 动画 ， 如 果 在 Activity 中 播放 此 类 动画 且 没 有 在 onDestroy 中 去 
停止 动画 ， 那 么 动画 会 一 直播 放下 去 ， 尽 管 已 经 无 法 在 界面 上 看 到 动画 
效果 了 ， 并 且 这 个 时 候 Activity 的 View 会 被 动画 持 有 ， 而 View 又 持 有 了 
Activity， 最 终 Activity 无 法 释放 。 下 面 的 动画 是 无 限 动画 ， 会 泄露 当前 
Activity， 解 决 方法 是 在 Activity 的 onDestroy 中 调用 animator.cancel0) 来 停 
止 动画 。 








protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_main); 
mButton = (Button) findViewById(R.id.button1); 
ObjectAnimator animator = ObjectAnimator.ofFloat(mButton, 

0, 360).setDuration(2000); 

animator .setRepeatCount (ValueAnimator.INFINITE); 
animator.start(); 


//animator.cancel(); 


15.1.4 Me DVR EE LL ANR AH ET 
AT 


啊 应 速度 优化 的 核心 思想 是 避免 在 主线 程 中 做 耗 时 操作 ， 但 是 有 时 
候 的 确 有 很 多 耗 时 操作 ， 怎 么 办 呢 ? 可 以 将 这 些 耗 时 操作 放 在 线程 中 去 


执行 ， 即 采用 异步 的 方式 执行 耗 时 操作 。 啊 应 速度 过 慢 更 多 地 体现 在 
Activity 的 局 动 速度 上 面 ， 如 果 在 主线 程 中 做 太 多 事情 ， 会 导致 Activity 
启动 时 出 现 黑屏 现象 ， 甚 至 出 现 ANR。Android 规 定 ，Activity 如 果 5 秒 
钟 之 内 无 法 啊 应 屏幕 触摸 事件 或 者 键盘 输入 事件 就 会 出 现 ANR， 而 
BroadcastReceiver 如 果 10 秒 钟 之 内 还 未 执行 完 操作 也 会 出 现 ANR。 在 实 
际 开 发 中 ，ANR 是 很 难 从 代码 上 发 现 的 ， 如 果 在 开发 过 程 中 遇 到 了 
ANR， 那 么 怎么 定位 问题 呢 ?” 其 实 当 一 个 进程 及 生 ANRT 以 后 ， 系 统 
人 txt， 通 过 分 析 这 个 文件 就 能 定位 
出 ANR 的 原因 ， 下 面 模拟 一 个 ANR 的 场景 。 下 面 的 代码 在 Activity 的 
onCreate 中 休眠 30s， 程 序 运 行 后 持续 点 击 屏幕 ， 应 用 一 定 会 出 现 ANR: 











protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_main); 


SystemClock.sleep(30 * 1000); 


这 里 先 假定 我 们 无 法 从 代码 中 看 出 ANR， 为 了 分 析 ANR 的 原因 ， 
可 以 到 处 traces 文 件 ， 如 下 所 示 ， 其 中 .表示 当前 目录 : 





adb pull /data/anr/traces.txt . 
traces 文 件 一 般 是 非常 长 的 ， 下 面 是 traces 文 件 的 部 分 内 容 : 


----- pid 29395 at 2015-05-31 16:14:36 ----- 
Cmd line: com.ryg.chapter_15 
DALVIK THREADS: 

(mutexes: tll=0 tsl=0 tscl=0 ghl=0) 


"main" prio=5 tid=1 TIMED_WAIT 


| group="main" sCount=1 dsCount=0 obj=0x4185b700 self=0x40 


| sysTid=29395 nice=0 sched=0/0 cgrp=apps handle=107395460 


| schedstat=( © © © ) utm=3 stm=2 core=2 


at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 


java.lang.VMThread.sleep(Native Method) 


java.lang.Thread.sleep( Thread. java:1031) 


java. lang. Thread.sleep(Thread.java:1013) 


android. 
com.ryg. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 


android. 


os.SystemClock.sleep(SystemClock.java:114) 
chapter_15.MainActivity.onCreate(MainActivity. Jj 
app.Activity.performCreate(Activity.java:5086) 
app.Instrumentation.callActivityOnCreate(Instru 
app.ActivityThread.performLaunchActivity(Activi 
app.ActivityThread.handleLaunchActivity(Activit 
app.ActivityThread.access$600(ActivityThread.ja 
app.ActivityThread$H.handleMessage(ActivityThre 
os.Handler.dispatchMessage(Handler.java:99) 
os.Looper.loop(Looper .java:137) 


app.ActivityThread.main(ActivityThread.java:491 


java.lang.reflect.Method.invokeNative(Native Method) 


java.lang.reflect .Method.invoke(Method. java:511) 


com.android.internal.os.ZygoteInit$MethodAndArgsCaller. 


com.android.internal.os.ZygoteInit.main(ZygoteInit.java 


dalvik.system.NativeStart.main(Native Method) 


"Binder_2" prio=5 tid=10 NATIVE 


| group="main" sCount=1 dsCount=0 obj=0x42296d80 self=0x69 


| sysTid=29407 nice=0 sched=0/0 cgrp=apps handle=175066408 


| schedstat=( © © © ) utm=0 stm=0 core=1 


#00 pc 0000cc50 /system/lib/libc.so (__ioct1+8) 

#01 pc 0002816d /system/lib/libc.so (ioct1+16) 

#02 pc 00016f9d /system/lib/libbinder.so (android: :IPCTh 
#03 pc 0001768f /system/lib/libbinder.so (android: :IPCTh 
#04 pc 0001b4e9 /system/lib/libbinder.so 

#05 pc 00010f7f /system/lib/libutils.so (android: : Thread 
#06 pc 00048ba5 /system/1lib/libandroid_runtime.so (andro 
#07 pc 00010ae5 /system/1lib/libutils.so 

#08 pc 00012ff0 /system/lib/libc.so (__thread_entry+48) 
#09 pc 00012748 /system/lib/libc.so (pthread_create+172) 


at dalvik.system.NativeStart.run(Native Method) 





从 traces 的 内 容 可 以 看 出 ， 主 线程 直接 sleep 了 ， 而 原因 就 是 
MainActivity 的 42 行 。 第 42 行 刚好 就 是 SystemClock.sleep(30 * 1000)， 这 
样 一 来 就 可 以 定位 问题 了 。 当 然 这 个 例子 太 直 接 了 ， 下 面 再 模拟 一 个 稍 
微 复杂 点 的 ANR 的 例子 。 


下 面 的 代码 也 会 导致 ANR， 原 因 是 这 样 的， 在 Activity 的 onCreate 中 
开启 了 一 个 线程 ， 在 线程 中 执行 testANRO， 而 testANRO 和 initViewO 都 
被 加 了 同一 个 锁 ， 为 了 百分之百 让 testANRO 先 获得 锁 ， 特 和 意 在 执行 
initView0 之 前 让 主线 程 休眠 了 10ms， 这 样 一 来 initView0 肯 定 会 因为 等 
待 testANRO 所 持 有 的 锁 而 被 同步 住 ， 这 样 就 产生 了 一 个 稍微 复杂 些 的 
ANR。 这 个 ANR 是 很 参考 意义 的 ， 这 样 的 代码 很 容易 在 实际 开发 中 出 
现 ， 尤 其 是 当 调 用 关系 比较 复杂 时 ， 这 个 时 候 分 析 ANR 日 志 束 显得 异常 
重要 了 。 下 面 的 代码 中 虽然 已 经 将 耗 时 操作 放 在 线程 中 了 ， 按 道理 就 不 
会 出 现 ANR 了 ， 但 是 仍然 要 注意 子 线程 和 主线 程 抢 占 同步 锁 的 情况 。 


























protected void onCreate(Bundle savedInstanceState) { 


为 了 分 析 问 题 ， 需 要 从 traces 文 件 着 手 ， 如 下 所 示 。 





at com.ryg.chapter_15.MainActivity.initView(MainActivity. j 


-waiting to lock <0x422a0120> (a com.ryg.chapter_15.MainAc 


by 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 
at 


at 


tid=11 (Thread-13248 ) 


com.ryg. 
android. 
android. 
android 
android. 
android. 
android. 
android. 
android. 


android. 


chapter_15.MainActivity.onCreate(MainActivity. j 
app.Activity.performCreate(Activity. java: 5086) 


app.Instrumentation.callActivityOnCreate(Instru 


.app.ActivityThread.performLaunchActivity(Activi 


app.ActivityThread.handleLaunchActivity(Activit 
app.ActivityThread.access$600(ActivityThread.ja 
app.ActivityThread$H.handleMessage(ActivityThre 
os.Handler.dispatchMessage(Handler.java:99) 
os.Looper.loop(Looper .java:137) 


app.ActivityThread.main(ActivityThread.java:491 


java.lang.reflect.Method.invokeNative(Native Method) 


java.lang.reflect.Method.invoke(Method.java:511) 


com.android.internal.os.ZygoteInit$MethodAndArgsCaller. 


com.android.internal.os.ZygoteInit.main(ZygoteInit.java 


dalvik.system.NativeStart.main(Native Method) 


"Thread-13248" prio=5 tid=11 TIMED_WAIT 


| group="main" sCount=1 dsCount=0 obj=0x422b0ed8 self=0x68 


sysTid=32687 nice=0 sched=0/0 cgrp=apps handle=175180428 


| schedstat=( © © © ) utm=0 stm=0 core=0 


at 
at 
at 
at 


at 


java. lang.VMThread.sleep(Native Method) 


java.lang.Thread.sleep( Thread. java:1031) 


java.lang.Thread.sleep(Thread.java:1013) 


android. 


com.ryg. 


os.SystemClock.sleep(SystemClock.java:114) 


chapter_15.MainActivity.testANR(MainActivity.ja 


at com.ryg.chapter_15.MainActivity.access$0(MainActivity. j 
at com.ryg.chapter_15.MainActivity$1.run(MainActivity.java 


at java.lang. Thread. run(Thread. java: 856) 








上 面 的 情况 稍微 复杂 一 些 ， 需 要 逐步 分 析 。 首 先 看 主线 程 ， 如 下 所 
示 。 可 以 看 得 出 主线 程 在 initView 方 法 中 正在 等 待 一 个 锁 
<0x422a0120>， 这 个 锁 的 类 型 是 一 个 MainActivity 对 象 ， 并 且 这 个 锁 已 
经 被 线程 id 为 11〈 即 tid=11) 的 线程 持 有 了 ， 因 此 需要 再 看 一 下 线程 11 
的 情况 。 














at com.ryg.chapter_15.MainActivity.initView(MainActivity.java 
-waiting to lock <0x422a0120> (a com.ryg.chapter_15.MainAc 
by tid=11 (Thread-13248) 


tid 是 11 的 线程 就 是 “Thread-13248”， 就 是 它 持 有 了 主线 程 所 需 的 
锁 ， 可 以 看 出 “Thread-13248” 正 在 sleep，sleep 的 原因 是 MainActivity 的 57 
行 ， 即 testANR 方 法 。 这 个 时 候 可 以 发 现 testANR 方 法 和 主线 程 的 
initView 方 法 都 加 了 synchronized 关 键 字 ， 表 明 它 们 在 竞争 同一 个 锁 ， 即 
当前 Activity 的 对 象 锁 ， 这 样 一 来 ANR 的 原因 就 明确 了 ， 接 着 就 可 以 修 
Peas T 





上 面 分 析 了 两 个 ANR 的 实例 ， 尤 其 是 第 二 个 ANR 在 实际 开发 中 很 
容易 出 现 ， 我 们 首先 要 有 意识 地 避免 出 现 ANR， 其 次 出 现 ANR 了 也 不 
要 着 急 ， 通 过 分 析 traces 文 件 即 可 定位 问题 。 





15.1.5 ListView 和 Bitmap 优 化 


ListView 的 优化 在 第 12 章 已 经 做 了 介绍 ， 这 里 再 简单 回顾 一 下 。 主 
要 分 为 三 个 方面 : 首先 要 采用 ViewHolder 并 避免 在 getView 中 执行 耗 时 
操作 ;其 次 要 根据 列表 的 滑动 状态 来 控制 任务 的 执行 频率 ， 比 如 当 列 表 
快速 滑动 时 显然 是 不 太 适 合 开 启 大 量 的 异步 任务 的 ， 最 后 可 以 尝试 开 局 
人 硬件 加 速 来 使 Listview 的 滑动 更 加 流畅 。 注 意 Listview 的 优化 策略 完全 适 
用 于 GridView。 





Bitmap 的 优化 同样 在 第 12 章 已 经 做 了 详细 的 介绍 ， 主 要 是 通过 
BitmapFactory.Options 来 根据 需要 对 图 片 进行 采样 ， 采 样 过 程 中 主要 用 
到 了 BitmapFactory.Options 的 inSampleSize 参 数 ， 详 情 这 里 就 不 再 重复 
了 ， 请 参考 第 12 章 的 有 关内 容 。 


15.1.6 ”线程 优化 


线程 优化 的 思想 是 采用 线程 池 ， 避 免 程序 中 存在 大 量 的 Thread。 线 
程 池 可 以 重用 内 部 的 线程 ， 从 而 避免 了 线程 的 创建 和 销毁 所 市 来 的 性 能 
开销 ， 同 时 线程 池 还 能 有 效 地 控制 线程 池 的 最 大 并 发 数 ， 避 免 大 量 的 线 
程 因 互相 抢占 系统 资源 从 而 导致 阻 豆 现象 的 有 发生。 因此 在 实际 开发 中 ， 
我 们 要 尽量 采用 线程 池 ， 而 不 是 每 次 都 要 创建 一 个 Thread 对 象 ， 关 于 线 
程 池 的 详细 介绍 请 参考 第 11 间 的 内 容 。 


15.1.7 一 些 性 能 优化 建议 


本 节 介 绍 的 是 一 些 性 能 优化 的 小 建议 ， 通 过 它们 可 以 在 一 定 程 度 上 


























避免 创建 过 多 的 对 象 ; 

不 要 过 多 使 用 枚 举 ， 枚 举 占用 的 内 存 空间 要 比 整 型 大 ; 

常量 请 使 用 static final 来 修饰 ; 

使 用 一 些 Android 特 有 的 数据 结构 ， 比 如 SparseArray 和 Pair 和 等， 它们 
都 有 具有 更 好 的 性 能 ; 

适当 使 用 软 引 用 和 软 引 用 ; 

采用 内 存 缓存 和 磁盘 绥 存 ; 

尽量 采用 静态 内 部 类 ， 这 样 可 以 避免 潜在 的 由 于 内 部 类 而 导致 的 内 
存 泄露 。 


15.2 内存 泄露 分 机 之 MAT 工 具 


MAT 的 全 称 是 Eclipse Memory Analyzer， 它 是 一 款 强 大 的 内 存 泄露 
分 析 工 具 ，MAT 不 需要 安装 ， 下 载 后 解压 即 可 使 用 ， 下 载 地 址 为 
http:/www.eclipse.org/mat/downloads.php。 对 于 Eclipse 来 说 ，MAT 也 有 
插件 版 ， 但 是 不 建议 使 用 插件 版 ， 因 为 独立 版 使 用 起 来 更 加 方便 ， 即 使 
不 安装 Eclipse 也 可 以 正常 使 用 ， 当 然 前 提 是 有 内 存 分 析 后 的 hprof 广 件 。 











为 了 采用 MAT 来 分 析 内 存 泄露 ， 下 面 模 拟 一 种 简单 的 内 存 泄 露 情 
况 ， 下 面 的 代码 肯定 会 造成 内 存 泄露 : 


public class MainActivity extends Activity { 
private static final String TAG = "MainActivity"; 
private static Context sContext; 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savediInstanceState) ; 
setContentView(R.layout.activity_main); 


sContext = this; 


} 


编译 安装 ， 然 后 打开 DDMS 界 面 ， 其 中 AndroidStudio 的 DDMS 位 于 
Monitor 中 。 接 着 用 鼠标 选中 要 分 析 的 进程 ， 然 后 使 用 待 分析 应 用 的 一 
些 功能 ， 这 样 做 是 为 了 将 尽量 多 的 内 存 泄露 暴露 出 来 ， 然 后 单 击 Dump 
HPROF fe 这 个 按钮 (对 应 图 15-1 中 底部 有 黑 线 的 按钮 )”， 等 待 一 小 有 段 








时 间 即 可 导出 一 个 hprof 后 缀 的 文件 ， 如 图 15-1 所 示 。 


G devices 2 | XE] OG 1% Bl O| Ge] ga) i 
ial 
Name 
4 Ẹ xiaomi-mi_2-5456024c Online 4.1.1 
com.ryg.chapter_15 4791 8600 / 8700 





图 15-1 DDMS 视 图 


导出 hprof 文 件 后 并 不 能 使 用 它 来 进行 分 析 ， 因 为 它 不 能 被 MAT 直 
接 识别 ， 需 要 通过 hprof-conv 命 令 转 换 一 下 。hprof-conv 命 令 是 Android 


SDK 提 供 的 工具 ， 它 位 于 Android SDK 的 platform-tools 目 录 下 : 


hprof-conv com.ryg.chapter_15.hprof com.ryg.chapter_15-conv.h 


当然 如 果 使 用 的 是 Eclipse 插件 版 的 MATI 的 话 ， 就 可 以 不 进行 格式 转 
换 了 ， 可 以 直接 用 MAT 插 件 打 开 。 








经 过 了 上 面 的 步骤 ， 接 下 来 残 可 以 直接 通过 MAT 来 进行 内 存 分 析 
了 。 打 开 MAT， 通 过 订单 打开 刚才 转换 后 的 com.ryg.chapter_15- 
conv.hprof 这 个 文件 ， 打 开 后 的 界面 如 图 15-2 所 示 。 


B comryg.chapter_15-convhprof £3 op 
in wi Hga 
i Overview 3 


~ Biggest Objects by Retained Size 





~ Reports ~ Stop By Step 


Leak Sust Component Report: Analyze objects which belong 
system overview to a common root package or class loader. 





Print the most expensive 
by class and by package. 









Detect classes loaded by 


ne 


图 15-2 MAT 的 内 存 分 析 主 界面 


如 图 15-2 所 示 ，MAT 提 供 了 很 多 功能 ， 但 是 最 常用 的 只 有 
Histogram 和 Dominator Tree， 通 过 Histogram 可 以 直观 地 看 出 内 存 中 不 同 
类 型 的 buffer 的 数量 和 占用 的 内 存 大 小 ， 而 Dominator Tree 则 把 内 存 中 的 
对 象 按照 从 大 到 小 的 顺序 进行 排序 ， 并 且 可 以 分 析 对 象 之 间 的 引用 关 
系 ， 内 存 泄 露 分 析 就 是 通过 Dominator Tree 来 完成 的 。 图 15-3 和 图 15-4 分 
别 是 MAT 中 Histogram 和 Dominator Tree 的 界面 。 


B com.ryg.chapter_15-conv:hprof 32 =o 
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Class Name Objects a 
[ <Regex = i Oe see “i eds <Nu Yenc Numenc> 
© bytel 1622 7.739,128 
@ chari] 9,949 553,144 
@ java.lang.String 11,363 272,712 
© jave.util. HashMap$HashMapEntry 5,414 129,936 
@intl 1,869 93,872 >= 93,872 
@javalang.string0 1,956 82,288 >= 94,488 
© java lang.Class 2,936 71,336 >= 7,456.9... 
© jave.util. HashMap$HashMapEntry{] 255 51112 >= 308,576 
© java.lang.Integer 2,514 40,224 >= 41,568 |z 
@ java. lang.Object{] 305 21,480 >= 6,359,5.. 
© java.util. HashMap 341 16,368 >= 324,648 
© java.utilzip.ZipEntry 224 16128 >= 24,136 
@ java.util. Hashtable$HashtableEntry 635 15,240 >= 23,560 
© org.apache.harmony.luni.util. woKeyHashMap$Entry 432 13,824 >= 23,232 
© java.lang.ref FinalizerReference 298 11,920 >= 13,352 
© java.util. LinkedHashMap$LinkedEntry 291 9,312 >= 84,968 
@ android.graphics.Rect 363 8,712 
© java lang.ref WeakReference 354 8,496 
© org.apache.harmony.luniutil. TwoKeyHashMap$Entryl] 9 8.368 >=31.600 而 
@ javalang.String00 5 7,088 >= 63,120 
© android.graphics.Bitmap 147 7,056 >= 7,309,6.. 
@ android.graphics.drawable.NinePatchDrawable 97 6,984 >= 9,696 
© java.util.Arraylist 280 6,720 >= 22,496 
© android.graphics.Paint 82 6,560 >= 7,576 
© android.content.res.MiuiResources$PreloadDrawableSource 258 6,192 >= 6,192 bs 


图 15-3 MAT 中 Histogram 的 界面 














9 com.ryg.chapter_15-conv.hprof 2 - 6 
i Bw Sl -Br|/Q|G~ a) © 
i Overview | Ml Histogram | Ts dominator tree 5% 
Jlass Name Shallow Heap Retained Heap Percentage ^ 
Pied i = a jumeric> Numeric> Numeric 

K res. 40 6,301,512 67.01% 

D endroid.graphics.Bitmap @ 0x419b9c00 48 1,048,656 11.15% 

四 dass android.text Html$HimlParser @ 0x41a460d8 System Class 8 126632 135% 

四 dass libcore.icu.TimeZones @ 0x41856380 System Class 40 108,888 116% 

4] class org.apache.harmony.security.fortress.Services @ 0x4198ba50 System Cla 32 70,280 0.75% 

四 class com.android.internal.R$styleable @ 0x4187f848 System Class 6,656 55,208 0.59% 

四 dass android.R$styleable @ 0x418daf30 System Class 6,064 51,240 0.54% 

因 dass android.view.View @ 0x4187dc58 System Class 1,056 46,604 0.50% 

L com.android.org.bouncycastiejce, provider,BouncyCastleProvider @ 0x4199db. 112 45,064 0.48% 

O miui.content.res. ThemeZipFile @ 0x41916038 40 41,824 0.44% E 
dÀ class android.content.res.MiuiResources @ 0x418e7e30 System Class 40 35,848 0.38% 7 
加 class android.textAutoText @ 0x41a389c0 System Class 56 29,088 0.31% 

L miui.content.res.ThemeZipFile @ 0x41928050 40 20,864 0.22% 
dÀ class libcore.net.MimeUtils @ 0x41b66b78 System Class 16 17,576 0.19% 

Pra) class java.io.Console @ 0x418548b0 System Class 16 17,520 0.19% 

回 charf8194] @ 0x4100c420 Africa/AbidjanAfrica/AccraAfrica/Addis AbabaAfrica 16,400 16,400 0.17% 
dÀ class libcore.icu.LocaleData @ 0x418539c8 System Class, Native Stack 8 15,856 0.17% 

AÀ dass java.lang.ref.FinalizerReference @ 0x41850f88 System Class 16 13,312 0.14% 

DD android.graphics.Ninepatch @ 0x4198e250 32 13.152 0.14% 
de) class com.android.org.bouncycastle.asni.pkes.PKCSObjectidentifiers @ 0x4192 504 12,816 0.14% 

4) class android.media. MediaFile @ 0x4195ca88 System Class 336 11,472 0.12% 

加 dass libcore.io.OsConstants @ 0x41856650 System Class 1,600 11,192 0.12% 

因 dass org.apache.harmony.security.utils.AlgNameMapper @ 0x41b892f0 Syster 24 11,152 0.12% 
© dass android.view.KeyEvent @ 0x4186aae8 System Class, Native Stack 1,112 10,008 0.11% 

&) dass com.android.i18n.phonenumbers.PhoneNumberUtil @ 0x41a364b8 Syste 184 9,640 0.10% 

4) dass android.opengl.GLES20 @ 0x418a81e0 System Class 1,216 8,480 0.09% ~ 


图 15-4 MAT 中 Ddominator Tree 的 界面 


为 了 分 析 内 存 泄 露 ， 我 们 需要 分 析 Dominator ”Tree 里面 的 内 存 信 
‘i, #&Dominator Tree 中 内 存 泄 露 的 原因 一 般 不 会 直接 显示 出 来 ， 这 个 
时 候 需 要 按照 从 大 到 小 的 顺序 去 排 租 一 过。 一 般 来 说 Bitmap 汇 露 往往 都 
是 由 于 程序 的 某 个 地 方 发 生 了 内 存 泄露 都 引起 的 ， 在 网 15-4 中 的 第 2 个 











结果 就 是 一 个 Bitmap 汇 露 ， 选 中 它 然 后 单 击 鼠 标 右键 ->Path To GC 
Roots-> exclude wake/soft references， 如 图 15-5 所 示 。 可 以 看 到 sContext 
引用 了 Bitmap 最 终 导 致 了 Bitmap 无 法 释放 ， 但 其 实 根 本 原因 是 sContext 
无 法 释放 所 导致 的 ， 这 样 我 们 就 找 出 了 内 存 泄 圳 的 地 方 。Path To GC 
Roots 过 程 中 之 所 以 选择 排除 弱 引 用 和 软 引 用 ， 是 因为 二 者 都 有 较 大 几 
率 被 gc 回收 挤 ， 它 们 并 不 能 造成 内 存 泄 露 。 











Class Name Shallow Heap Retained Heap 


4 || android.graphics.Bitmap @ 0x419b9c00 
a‘ mBitmap android.graphics.drawable.BitmapDrawable$BitmapState @ 0x418ac188 
a "E [98] java.lang.Object[254] @ 0x41ab9d90 
a) mValues android.util.LongSparseArray @ 0x4190bed8 
9 sPreloadedDrawables class android.content.res.Resources @ 0x4188a3cl 
aD mBitmap android.graphics.drawable.BitmapDrawable @ 0x422c9ec8 
a | mCurrDrawable android.graphics.drawable.StateListDrawable @ 0x422c9cd0 
a ' 国 mBackground com.android.internal.policy.imp!.PhoneWindow$DecorView @ 
a {| mDecor com.android.internal.policy.impl.PhoneWindow @ 0x422c6d90 
4 O mwindow com.ryg.chapter_15.MainActivity @ 0x422c6a38 


T mOuterContext android.app.Contextimp| @ 0x422c6bf8 
> Total: 2 entries 
> Total: 2 entries 





图 15-5 Path To GC Roots 后 的 结 


在 Dominator Tree 界 面 中 是 可 以 使 用 搜索 功能 的 ， 比 如 我 们 尝试 搜 
索 MainActivity， 因 为 这 里 我 们 已 经 知道 MainActivity 存 在 内 存 泄露 了 ， 
搜索 后 的 结果 如 图 15-6 所 示 。 我 们 发 现 里 面 有 6 个 MainActivity 的 对 象 ， 
这 是 因为 每 次 按 back 键 退出 再 重新 进入 MainActivity， 系 统 都 会 重新 创 
建 一 个 新 的 MainActivity， 但 是 由 于 老 的 MainActivity 无 法 被 回收 ， 所 以 
就 出 现 了 多 个 MainActivity 对 象 的 情形 。 另 外 MAT 还 有 很 多 其 他 功能 ， 
这 里 就 不 再 一 一 介绍 了 ， 请 读者 自己 体验 吧 。 
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i Overview| lll Histogram | Ps dominator tree °2 ta path2gc [selection of 'Bitmap @ 0x419b9c00] -excludes java.lang.ref WeakReferen 





Class Name Shallow Heap Retained Heap Percentage 
JP *MainActivity* <Numeric= <Numeric>  <Numeric> 

» [) com.ryg.chapter_15.MainActivity @ 042290018 184 2,200 0.02% 
> D com.ryg.chapter 15,MainActivity @ 0x4229e300 184 2,200 0.02% 
» [O com.ryg.chapter_15.MainActivity @ 0x422bfb38 184 2,200 0.02% 
> D com.ryg.chapter_15,MainActivity @ 0x422c6a38 184 2,200 0.02% 
b [L com.ryg.chapter_15.MainActivity @ 0x422b2338 184 2,176 0.02% 
b D comsryg.chapter_15.MainActivity @ 0x422alaa0 184 2,128 0.02% 
» [Q java.lang.String @ 042290358 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
» D java.lang.String @ 0x422925e0 comuryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
» D java.lang.String @ 0x422a2d10 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
» D java.lang.String @ 0x422b9510 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
» [ java.lang.String @ 0x422c0410 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
» D java.lang.String @ 0x422c7310 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
ò 四 dass com.ryg.chapter_15.MainActivity @ 0x422a1530 System Class 16 104 0.00% 
b å] java.lang.String @ 0x422a1a50 MainActivity Unknown 24 64 0.00% 


È Total: 14 entries (12,872 filtered) 


图 15-6 Dominator Tree 的 搜索 功能 


15.3 ”提高 程序 的 可 维护 性 


本 市 所 讲述 的 内 容 是 Android 的 程序 设计 思想 ， 主 由 是 如 何 提 高 代 
码 的 可 维护 性 和 可 扩展 性 ， 而 程序 的 可 维护 性 本 质 上 也 包含 可 扩展 性 。 
本 节 的 切入 点 为 : 代码 风格 、 代 码 的 层次 性 和 单一 职员 原则 、 面 向 扩展 
编程 以 及 设计 模式 ， 下 面 围 绕 着 它们 分 别 展开 。 


可 读 性 是 代码 可 维护 性 的 前 提 ， 一 段 别 人 很 难 读 异 的 代码 的 可 维护 
生 显然 是 极 兰 的 。 而 展 好 的 代码 风格 在 一 定 程度 上 可 以 提高 程序 的 可 读 
生 。 代 码 风格 包含 很 多 方面 ， 比 如 命名 规范 、 代 码 的 排版 以 及 是 否 写 注 
释 等 。 到 底 什 么 样 的 代码 风格 是 良好 的 ? 这 是 个 仁者 见 仁 的 问题 ， 下 面 
是 笔者 的 一 些 看 法 。 





J 


一 :二 ”一 -一 


(1) 命名 要 规范 ， 要 能 正确 地 传达 出 变量 或 者 方法 的 含义 ， 少 用 
缩写 ， 关 于 变量 的 前 缀 可 以 参考 Android 源 码 的 命名 方式 ， 比 如 私有 成 
员 以 m 开 头 ， 静 态 成 员 以 s 开 头 ， 弟 量 则 全 部 用 大 写字 母 表示 ， 等 等 。 








(2) 代码 的 排版 上 需要 留 出 合理 的 空白 来 区 分 不 同 的 代码 块 ， 其 
中 同类 变量 的 声明 要 放 在 一 组 ， 两 类 变量 之 间 要 留 出 一 行 空白 作为 区 


pa 





(3) 仪 为 非常 关键 的 代码 添加 注释 ， 其 他 地 方 不 写 注释 ， 这 就 对 
变量 和 方法 的 命名 风格 提出 了 很 高 的 要 求 ， 一 个 合理 的 命令 风格 可 以 让 
读者 阅读 源码 就 像 在 阅读 注释 一 样 ， 因 此 根本 不 需要 为 代码 额外 写 注 


FE 
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试图 在 一 个 方法 或 者 一 个 类 中 去 全 部 实现 ， 而 要 将 它 分 成 儿 个 子 逻 辑 ， 
然后 每 个 子 逻 辑 做 自己 的 事情 ， 这 样 既 显 得 代码 层次 分 明 ， 叉 可 以 分 解 
任务 从 而 实现 简化 逻辑 的 效果 。 单 一 职 贡 是 和 层次 性 相关 联 的 ， 代 码 分 
层 以 后 ， 每 一 层 仅 仅 关 注 少 量 的 人 逻辑， 这 样 束 做 到 了 单一 职 贡 。 代 码 的 
层次 性 和 单一 职 贡 原则 可 以 以 公司 的 组 织 结构 为 例 来 说 明 ， 比 如 现在 有 
一 个 复杂 的 需求 来 到 了 部 门 经 理 面前 ， 如 有 果 部 门 经 理 需 要 给 每 个 员工 来 
安排 具体 的 任务 ， 那 显然 他 会 最 得 很 宗 ， 因 为 他 必须 要 了 解 每 个 员工 的 
工作 并 最 终 收 集 每 个 员工 的 完成 情况 ， 这 个 时 候 整 个 工作 过 程 就 缺少 了 
层次 性 ， 并 且 也 违背 了 单一 职责 的 原则 ， 毕 葛 经 理 的 主要 工作 是 管理 团 
队 而 不 是 给 员工 安排 任务 。 如 果 采 用 分 层 的 思想 要 怎么 做 昵 ? CAE 
可 以 将 复杂 的 任务 分 成 在 干 份 ， 每 一 份 交 给 一 个 主管 处 理 ， 然 后 剩 下 的 
事情 经 理 就 不 用 管 了 ， 他 只 需要 管理 主管 即 可 。 对 于 主管 来 说 ， 分 配给 
他 的 任务 相对 于 整个 任务 就 简单 了 不 少 ， 这 个 时 候 他 再 拆 解 任务 给 组 
员 ， 这 个 时 候 真正 到 达 组 员 手 里 的 任务 其 实 就 没有 那么 复 洒 了 ， 这 其 实 
类 似 于 分 治 俩 略 。 这 样 一 来 整个 工作 过 程 就 具有 了 三 层 的 结构 ， 并 且 每 
一 层 有 不 同 的 职责 ， 一旦 出 现 了 错误 也 可 以 很 方便 地 定位 到 具体 的 地 
方 。 




















程序 的 扩展 性 标志 着 开 发 人 员 是 否 有 足够 的 经 验 ， 很 多 时 候 在 开发 
过 程 中 我 们 无 法 保证 已 经 做 好 的 需求 不 在 后 面 的 版 本 发 生变 更 ， 因 此 在 
写 程序 的 过 程 中 要 时 刻 考虑 到 扩展 ， 考 虑 着 如 琳 这 个 逻辑 后 面 发 生 了 改 
变 那 么 需要 做 哪些 修改 ， 以 及 怎么 样 才能 降低 修改 的 工作 量 ， 面 向 扩展 
编程 会 使 程序 具有 很 好 的 扩展 性 。 














恰当 地 使 用 设计 模式 可 以 提高 代码 的 可 维护 性 和 可 扩展 性 ， 但 是 
Android 程 序 容 易 有 性 能 瓶 肛 ， 因 此 要 控制 设计 的 度 ， 设 计 不 能 太 牵 
强 ， 人 否则 就 是 过 度 设计 了 。 第 见 的 设计 模式 有 很 多 ， 比 如 单 例 模式 、 工 


三 模 式 以 及 观察 者 模式 等 ， 由 于 本 书 不 是 专门 介绍 设计 模式 的 书 ， 因 此 
这 里 就 不 对 设计 模式 进行 详细 的 介绍 了 ， 读 者 可 以 参看 《大 话 设 计 模 
式 》 和 《Android 源 码 设计 模式 解析 与 实战 》 这 两 本 书 ， 为 外 设计 模式 
需要 理解 后 灵活 运用 才能 发 挥 更 好 的 效果 。 
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